Tech Decay: Tech Debt is Worse Than You Think
Any software engineer with a little bit of experience knows about technical debt. Though it’s typically related to a conscious decision to “do it wrong” temporarily (basically, so you can deliver sooner), the term can encompass other software issues, from defects to bad design to anything that makes you want to rewrite the code.
The term is used as a metaphor for taking out a loan, where you “pay interest” over time because you haven’t rewritten the offending code. However, there are a number of aspects of “I need to rewrite this code,” that the definition doesn’t quite cover.
In fact, let’s create a non-trivial project in which no “tech debt” is incurred. This means that you write it exactly the way you wanted it to be. You used the right framework, the right libraries, the right design. Let’s say that it doesn’t even have any defects!
You’re still going to need to rewrite it…eventually. That’s because there’s “tech decay.” Those frameworks and libraries you used? They will need to be upgraded as the authors continue to update, change, tweak, or improve them. Just because your code doesn’t have any defects doesn’t mean that everything it’s dependent upon doesn’t.
What if that framework has no updates? That’s actually a sign that it’s a dying or dead framework, which means that you need to use something else. No framework or library has been around forever, and the chances that the one you chose to use will be around forever is slim to none.
There’s also the very real likelihood that the reasons for the algorithms in the code will be forgotten. We don’t comment our code to explain what it does (usually); we comment it to explain why we did what we did. What happens when you implement a business rule, leave the project, and no one knows why the rule was there in the first place? That’s the software decaying.
Tech decay is the aging and deterioration of software that requires some form of change to the software to minimize the cost of future changes to it. In other words, you have to “fix it” in order to improve it. Otherwise, improvements will cost more than they should. Software can get to the point where any change causes a high risk of failure.
Decay doesn’t just affect code. Configuration, tools, and anything else used to run the software can be a part of that decay. For example, a build tool can cease to be supported and become no longer available. The underlying operating system the software must execute on may become outdated and unavailable.
Measuring Tech Decay
Generally speaking, tech decay can be measured as a percentage of the code base. That percentage represents the amount of code, configuration, etc. that needs to change in order to get the software to a high-functioning state. High-functioning in this case refers to the ability to optimally improve the software (i.e., add new features).
Understanding what needs to change isn’t necessarily an easy question to answer. It also doesn’t explain the cost associated with “fixing” it. The cost of fixing decaying software is based upon the amount of work necessarily to change the software to where it “should” be (that is, the optimal state for adding the new features that you need or want to make).
You could, for example, analyze each section of code, configuration, etc. that needs to be changed and define the target change. For example, you might identify a section of code for a simple refactor. In a more extreme case, you may identify the need to replace an entire framework the code is based upon, which may require man-years of development effort.
Eating the Elephant
A structured approach to addressing tech decay would involve not only identifying those areas that need fixed and the target change, but also to identify the return on investment: the cost of change versus the value of the change. The value of the change would be based upon the impact the change provides. It may not only be as simple as improving the ability to add new features later. It may be improvements in security, performance, or other non-functional improvements.
Fixing a decaying software project can take many forms. For monolithic projects, there’s the Strangler Fig Pattern. Most cases, though, some form of refactoring is sufficient. Depending upon the amount and significance of the decay, care and creativity may be required. The following process can be helpful in getting from Point A to Point B:
- Identify the decay (where and what)
- Identify the target change (what’s the solution for each area; note that there may be multiple options for solving a given area)
- Prioritization of each area based upon a calculation of the probable cost and expected return
- Execution of the backlog of changes
It’s also helpful to review the results after a change to double-check the accuracy of the return on investment (actual value minus the actual cost). This can be useful as feedback for the next change.
That’s All Nice and Good, But…
Generally speaking, software engineers like working with a clean codebase. Though they may write spaghetti code to get the job done, they typically don’t like working with someone else’s dirty laundry. They like to fix things (that is, they like to solve problems and build solutions). However, their time is expensive and projects typically take longer than expected. Getting buy-in from management is difficult, if not impossible.
There is a perception, sometimes, that once written, code does not decay. It may be acknowledged that there may be unknown or hidden defects, but if it works today, it will always work. Maintenance is for fixing defects or adding minor features. It’s common for the “business” (management, stakeholders, customers, etc.) to misunderstand the concept of decay. Because we tend to use the term “tech debt,” we don’t give the impression that the software is actually deteriorating over time (meaning, tech debt is something that’s introduced into the software, not something that happens over time, once the software is already developed).
Tech decay is more impactful in certain industries or contexts. For example, an embedded software may last long after the containing device does, in which case, the decay is irrelevant. However, on the other extreme, decay is why some SaaS providers may lose out to other up-and-coming software providers due to their ability to write a new solution before the market leader can clear up the natural decay of their golden goose.
When approaching management, focus on measuring the decay and calculating the cost. For example, The One Line of Code Process can sometimes be used to identify decay in the software that is expressed in the build and deploy process. There are a number of ways of measuring decay, such as the introduction of defects from changes, the average time to add new features, average cost per feature, etc. Upper management will typically listen to metrics that translate easily into the bottom-line.
The fundamental aspect of tech decay is to acknowledge that software is never “done” (unless it’s no longer used). Even a clean house will get dirty over time, even if no one is living in it. Software decays unless it’s explicitly kept up, cleaned, and revitalized.
