Technical Debt: Beyond the semantics

Somehow, the notion of being in debt of any kind is typically not attractive. It need not be so. Just as in our houses, we have to keep putting away dishes, taking out the trash or practice Spring cleaning - a consequence of software development is Technical Debt. It is inevitable. It should be actively managed.

Technical debt is a concept in software development that describes when engineering teams prioritize speed and expedited delivery over perfect code. Incurring technical debt is often a natural trade off when getting a feature, piece of functionality or important project shipped quickly rather than plan and build with future efficiency top of mind.

Some consider technical debt as the expected cost to rework existing features or components of a system to better support the longer-term needs of the organization.

When technical debt is incurred as a result of exploring a new feature, a conscious strategy will be to minimize the investment until the value of the feature is proven, ultimately avoiding the cost of over-engineering. In this respect, technical debt is a great counterbalance to over-engineering, particularly when the additional cost is high and the expected benefit is still unknown.

WHAT CAUSES TECH DEBT?

1. Technical debt doesn’t just happen because of poor code quality or shoddy design. Often, it’s the result of a series of good or necessary decisions made over time—actions individually justified by their immediate ROI or the needs of a project.
2. Skipping a software update or infrastructure upgrade because there wasn’t a clear business benefit; building point-to-point interfaces into a small app to get it into the business’ hands more quickly; choosing a product one already owns to build a prototype in order to avoid a drawn-out vendor selection and procurement process.
3. Including known non-critical bugs; shortcut implementations that need to be revisited; messy code that needs refactoring; missing error conditions handling; missing automated/unit tests; simplistic logic; and unoptimized algorithms.

HOW DOES TECH DEBT MANIFEST?

1. As a deficiency in a system that makes it harder to change, improve or maintain. If a team is losing velocity, this is a good indicator that tech debt may exist.
2. When the business requests a new feature or capability, teams gather the requirements and estimate the effort. When the estimation is much higher than anticipated, it’s usually a clear sign of some outstanding debt on the technical “balance sheet.”
3. Well-written code poorly maintained can turn into technical debt. Or code can turn into debt if it once served a purpose but is now unused because the business or technical needs changed.
4. Delivery teams calling out technical debt before it occurs, but that’s ideal and not always reality.
5. By writing too much code or the wrong code. 
6. It can also be due to omission. Missing code can take the form of missing error handling, logging to enable observability, or metrics to properly understand system performance. 
7. It could also take the form of not writing tests - where test code coverage is too low. Or where integration tests are faulty or incomplete. 
8. Automated checks for test coverage help uncover a deeper issue or uncover any weaknesses in design. 
9. The worst and most mind-bending form of technical debt is technical risk below the surface of clear observation. This form of technical debt arises from unforeseen dependencies, creeping system complexity, or the violation of deep system constraints due to fundamental, system-wide assumptions. Such 'landmines' usually remain invisible until there is a blow-up. 

CONSEQUENCES OF IGNORING TECH DEBT

Accounting for technical debt “is more of an art than a science,” and is a necessary part of good business strategy. It needs to be accounted for down the line in the overall schedule and not ignored, or else it creates more technical debt. Technical debt can have some significant implications for any business if it is not effectively measured and managed. 

MEASURING AND MANAGING TECH DEBT

1. One can minimize unintentional technical debt by taking steps to prevent it from happening through good engineering practices such as reviews, static analysis, and training.
2. Regardless of what prevention is in place, technical debt will still accumulate. It’s most important to continually work on paying down the debt to keep the code healthy. This requires continuous communication and negotiation between engineering and product management teams (or business).
3. A prudent allowance for technical debt can actually aid agility over time.
4. The typical engineering metrics some companies focus on include user story cycle time, human time spent on release activities, and a ratio of new feature development vs. maintenance on the product (or application). Measures of quality and stability, including metrics around test automation coverage are made.
5. Technical debt is best managed in a backlog just as managing features. Engineers transparently communicate technical debt backlog to product management, so that it is prioritized.
6. From their experience managing past technical debt, some software development organizations look at building features differently. Before jumping into features and larger technical debt payments, they write out detailed 'technical implementation plans'. Such plans, propose ideas clearly as well as get ideas from reviewers. This helps expose possible debt being taken up, but also track the reasoning for a decision - of why they were fine with that decision.
7. The best source of insight on technical debt are those who work closest to the codebase – The Engineers or Developers. Some organizations manage their tech debt by encouraging their Engineers to talk about it in the open and make them know that accruing this sort of debt is normal and necessary. It creates a shared understanding of immediate and longer-term costs and benefits to technical choices. This reduces the pressure for Engineers to hide their debt and reduces the chance for bugs, broken products, and unhappy customers.

IN SUMMARY

A finished software product with no technical debt would be, by definition, perfect in every possible way. This is, however, impossible. The way financial debt can be beneficial to building credit, when tech debt is accrued and “paid back” intelligently, it can increase the overall stability and flexibility of the existing system, and/or improve the productivity of the Engineering team. Technical debt is a challenging phenomenon to measure, as real-world software is complex by nature. As with financial debt, technical debt compounds over time.  Technical Debt isn’t something that can be effectively dealt with on a one-off or as-needed basis. It should be actively managed.