Mind Crafting – Managing Tech Debt
25.10.2023 | 4 min read
Agility and innovation are paramount in software development and the concept of "tech debt" has become a common buzzword. Radosław Litman, our Senior JS Developer at 10Clouds, delved into this topic during his presentation as part of our Mind Crafting celebration for Programmer's Day. In this blog post, we'll explore why tech debt matters, what it entails, its various types, causes, consequences, and most importantly, how to manage it effectively.
Why should we care about tech debt?
Tech debt is a common and inevitable part of software development that needs careful management.
It's crucial to debunk the misconception that tech debt is solely the result of developers' laziness or poor decision-making.
Instead, it often arises as a technical outcome of decisions made to save time and costs during project development. Like financial debt, tech debt accrues interest over time, and addressing it requires an investment of time and resources.
What is tech debt?
Tech debt encompasses more than just coding errors or shortcuts. It refers to any technical compromise made during development that can cause problems later.
It may include choosing cheaper but less scalable services, skipping automated testing, deferring refactoring, neglecting coding standards and tools, or even failing to document important decisions. It's essential to differentiate tech debt from normal tracked bugs, missing features, prototypes, and non-problematic aspects of the code.
What are the different types of tech debt?
Tech debt can be categorized along two axes: deliberate vs. accidental and reckless vs. prudent. Prudent tech debt involves reasonable compromises due to constraints like time or budget, such as choosing a less scalable service. Reckless tech debt, on the other hand, stems from issues like lack of knowledge, unchecked code quality, or complex business logic. Recognizing the type of tech debt is crucial for effective management.
Why do we get tech debt?
Several factors contribute to the accumulation of tech debt, including budget constraints, rapidly changing requirements, bad architecture, not following YAGNI (You Ain't Gonna Need It) or overengineering, lax standards, and frequent team structure changes. A lack of technical leadership can also lead to tech debt, as the absence of clear guidance often results in suboptimal decisions.
What are the consequences of tech debt?
The repercussions of tech debt can be severe, affecting both project development and team morale. It can slow down feature delivery, lead to poorly implemented features, and demoralize developers. It can result in missed deadlines, higher compensation demands from developers, lower project quality, and problems with keeping Service Level Agreements (SLAs), client satisfaction, and contractual penalties. Unmanaged tech debt can be a ticking time bomb for any project.
How can we manage it?
Managing tech debt involves both avoidance and tracking as well as actively addressing and paying it off.
Avoiding and tracking: Documenting decisions that lead to tech debt and keeping track of identified tech debt are essential practices. Avoid using prototypes in production code, enforce coding standards, and conduct regular retrospectives to analyze problems. Measure code quality using specialist tools to stay informed about tech debt levels.
Managing and paying off: Make tech debt visible through boards or tracking tools. Inform clients about associated risks and treat it as a business risk. Fix issues as they arise, add specific tech debt tasks to sprints, and dedicate full cleanup sprints to address tech debt systematically. Communicate in business language to ensure everyone understands the risks and costs involved.
Acquiring tech debt is common and when it’s deliberate and properly handled, can serve as a useful tool for gaining time and, sometimes, saving costs or moving them to the future. However, it should be treated as a loan that requires careful management. Tracking and addressing tech debt is essential, as neglecting it can lead to long-term problems, potentially jeopardizing features or entire projects.