Addressing Tech Debt
Signs tech debt has become a limiting factor and how to address the problem.
This week I read Accumulation of Tech Debt, an article in a series called “Bottlenecks of Scaleups” by Tim Cochran, Carl Nygard, Kennedy Collins, Keyur Govande, Rick Kick, and Roni Smith from Thoughtworks. Their series examines the common bottlenecks that affect startups as they scale, along with the warning signs and strategies for overcoming those bottlenecks. This article focuses on the challenge of technical debt.
My summary of the paper
Prudent technical debt is healthy and desired, especially in the initial phases of a startup’s journey. However, as a company scales up, it can become a limiting factor in their growth unless an appropriate balance is achieved between making investments in feature delivery versus technical debt. To help with this problem, this article outlines the different types of debt, the warning signs that it is becoming a bottleneck, and strategies for mitigating the negative impact of technical debt.
The different types of technical debt
Technical debt is an ambiguous term which commonly refers to one or more of the following 10 types:
Code quality. Code that is brittle, hard to test, hard to understand, or poorly documented will make all development and maintenance tasks slower and will degrade the "enjoyment" of writing code while demotivating engineers.
Testing. A lack of unit or E2E tests means that developers can’t quickly get confidence that their code will not break existing functionality and dependencies.
Coupling. Coupling between modules or services leads to teams potentially blocking each other, slowing down delivery speed.
Unused features. More features creates more conditions and more edge cases that developers have to design around, which erodes the delivery speed.
Out of date libraries or frameworks. Teams are unable to take advantage of new improvements and remain vulnerable to security problems. This also can slow down the onboarding of new hires and cause frustration for current developers who are forced to work with older versions.
Tooling. Inefficient tools (both proprietary and third-party) can introduce friction or overhead for developers, slowing delivery speed.
Reliability or performance issues. These can affect the customer experience as well as the ability to scale the business.
Manual processes. When a part of the product delivery isn't automated, it requires more manual time and effort.
Automated deployments. Automated deployment workflows enable the ability to deliver features to customers continuously and at will.
Knowledge sharing. Missing or difficult-to-find information is a form of technical debt, as it makes it difficult for new employees and dependent teams to get up to speed.
Technical debt can often refer to new functionality: “Startups often tell us about being swamped with technical debt, but under examination they’re really referring to the limited functionality of the technical platform, which needs its own proper treatment with planning, requirement gathering, and dedicated resources.”
Some types of technical debt can be “harder to spot and harder to point to a direct impact, such as code that is difficult to work with or short repeated manual processes. The best way to identify them is with feedback from the teams that experience them day-to-day.”
Signs that technical debt is becoming a bottleneck
Value lead time: Looking at the end-to-end process of providing value to users and how it trends over time will highlight friction between technical debt and other problems.
Impact to end user: Latency in the systems, customer onboarding time, and quality issues will impact the customer — a technical shortcut could be the root cause.
Developer satisfaction: Listening to your developers’ complaints will bring up fundamental issues in the technical platform, enabling prioritization of what will impact them the most.
Ability to onboard new developers: Looking at the onboarding process and the satisfaction of new developers can surface problems, which long-term employees have built a habit of avoiding.
Degradation in Non-Functional measures: Run-time infrastructure costs, performance and availability can all be indirect indicators of excessive technical debt impacting business outcomes.
When a company ends up with a lot of technical debt, it usually isn’t due to one event but rather a series of decisions and trade-offs made under pressure. It’s also “natural for developers to use the current state as an indicator of what is acceptable,” leading to more debt.
Strategies for addressing technical debt
The approach for addressing technical debt should come from an organization’s technical strategy, set by its leaders. It should be intentional, clear, and re-evaluated over time. Four key strategies can help organizations be successful:
Transparent information: Technical strategy must be informed by information on signals such as business performance, product direction, or what customers are saying about the product.
Clear end-to-end ownership: “As teams grow and take on new duties, it becomes increasingly difficult to find an owner for older code,” which means teams are less incentivized to fix problems. Ensure all systems have owners.
Empowered teams: “There should be an agreed process to tackle and monitor technical debt continually.” Addressing technical debt should be part of the natural flow of work for teams.
Lightweight process: “Lightweight checks and balances such as automated checks or architectural peer review can help enforce policies and aid developers.”
The authors share that they’ve found that “taking an iterative approach and letting the metrics combined with current development activity guide the investment in resolving tech debt results in better outcomes.”
Final thoughts
The term “tech debt” is frequently tossed around without developers or business stakeholders having a clear understanding of what the problem really is. This article can help guide us toward having clearer discussions: what type of debt are we talking about, and what information demonstrates that it is negatively affecting a team’s ability to deliver? I look forward to reading more from this article series from Thoughtworks.
That’s it for this week! If you know someone who would enjoy this newsletter, please consider sharing it with them.
As always, reach out with thoughts about this newsletter on LinkedIn, or reply to this email.
-Abi
Technical Debt is the refactoring effort needed to add a feature non-invasively.
Toward a Galvanizing Definition of Technical Debt https://michaelfeathers.silvrback.com/toward-a-galvanizing-definition-of-technical-debt
"Technical Debt" is a phrase I consciously avoid using because people only hear the word "Optional".
Instead I try to find the appropriate Non-Functional Requirement, or System Quality Attribute that is failing due to the Tech Debt and use that word instead.