Too much debt, whether financial or technical, can cripple an organization’s freedom to move forward. However, unlike financial debt whose cost is spelled out in a statement, the burden of technical debt to a company is not immediately clear, as it cannot be measured by simply reading the code. Furthermore, most discussions about technical debt fail to consider its impact on businesses, and instead, center on the technical characteristics of the code. We can certainly reach a consensus on how well written a piece of code is (e.g. on a scale of 1 to 10); yet, this consensus does not necessarily predict the burden that poor code creates for customers and the company’s bottom line. For example, a poorly written piece of code in a module that will see little change in the future can probably be ignored, while a few lines of code that don’t catch an exception in a highly used system can annoy and even disengage end-users, thus ultimately impacting revenue. Consequently, the importance of technical debt must be evaluated from the customer’s perspective, rather than from a technical perspective.
The Benefits to Customers of Fixing Technical Debt
Whenever possible, an engineering team fixes technical debt within the scope of product releases. However, a challenge emerges when the work required to address the technical debt competes with resources that could deliver customer visible features. The oft-asked question, “Should we pay back our technical debt, or should we develop new features for our customers?” frames the debate incorrectly. It implies that fixing technical debt brings no value to our customers. In reality, our customers benefit in a variety of ways when we resolve technical debt:
- Once the legacy code has been refactored, the development velocity is increased, leading to faster time to market, and thus a richer product for customers
- Fixing technical debt leads to a more stable product as the quality is improved by eliminating poorly written and fragile code
- Greater performance and scalability can be achieved, providing a more responsive and robust product for the end user
- Reducing operational expenses allows for a lower cost for the customer
Surefire Signs Technical Debt Is Killing your Company
Addressing technical debt can be a resource intensive endeavor and typically requires a consensus from several key decision makers; heads of tech, finance, operations, sales and product must be onboard. Reaching a consensus among these stakeholders about a plan to address the technical debt first requires that we prove the existence of the issues, determine their severity and articulate the benefits of addressing them. With that in mind, here are simple ways for non-technical executives to recognize that technical debt could be undermining a company’s success:
- Simple enhancements take much longer for one area of code than others
- Bugs surface after release to production (sometimes in areas unrelated to recent changes)
- The engineering team frequently has to extend the schedule for features touching a given area of code
- The system crashes during periods of high volume traffic
- Engineers are reluctant to work on specific areas of code
Sure, there can be other reasons for these symptoms, but a short discussion with the VP Engineering or CTO will quickly confirm the diagnostic.
How to Frame the Question Over the Proper Timeframe and Find Resources
In addition, it’s critical to frame the evaluation in the proper time frame. If we allocate half of the engineering team to fix technical debt for the next quarter, it’s pretty clear that at the end of the quarter, we will have delivered half the customer-visible features compared to what a fully staffed team would have delivered. This does not look like a good outcome. On the other hand, if we use a 2-year horizon (or longer) to evaluate the ROI of fixing technical debt, the ROI becomes favorable because we now account, not only for the costs, but also the benefits of having fixed technical debt, such as accelerated velocity, improved quality, etc. over the following 7 quarters. Departments and teams will also approach the situation with particular biases. Sales may be dead set on new features while the engineering team swears it cannot implement new features unless technical debt is addressed first. Furthermore, the mountain of technical debt seems sometimes insurmountable and beyond the capacity of the existing team. To resolve seemingly irreconcilable points of view between teams, consider engaging outside resources to act as independent arbiters and attack the refactoring project. This solution gives the existing team a chance to focus on the customer-facing roadmap, and presents the technical debt effort as a pure cost item, which can be weighed against the customer benefits over the next 2-3 years. While the customer impact of technical debt isn’t as glaringly obvious as failing to provide the same feature as a competitor, it can have just as much of an impact on a product’s success. A slow pace of new features or poor responsiveness of the app will disgruntle existing customers, and thus negatively affect usage, and ultimately renewal rates. So, if you find that some areas of the product always seem to take longer to develop, have lots of bugs and low performance, or fail to inspire the engineers, it’s time to ask your VP of Engineering about strategies to fix the technical debt. If you’d like to learn more about best practices for measuring and managing your technical debt, click here to download Bernard Fraenkel’s Technical Debt White Paper.