Just recently, the Michigan Secretary of State faced a big problem. Their digital system stopped working. They had spent too many years updating an old system, trying to make incremental fixes here and there. They didn’t have a plan in place for the software retirement, so before a new solution could be enacted, they faced a total breakdown. Therein lies the danger of ignoring technical debt.

At Springthrough, we often help customers with their technical debt. Technical debt isn’t unlike financial debt. It accumulates over time. Its ‘interest’ grows rapidly if not properly dealt with, can be costly to resolve, and can cause a large business impact if unchecked. Unfortunately, most people don’t understand how technical debt is accumulated or how to budget for it.  With technology being so core to business, technical debt is an important thing to plan for, manage, and recognize as part of your greater technology strategy.  

Fortunately, more organizations plan for hardware technical debt than ever before. They know that cellphones need to be replaced every 2 - 3 years (tops), laptops need to be replaced every 3 - 4 years, and servers every 5 years (or maybe switch to Cloud services). It is commonly understood that maintenance and care is needed to support the hardware ecosystem. Organizations know how to budget for it. 

So, what about software?

What causes technical debt in software? Does your organization have a budget and strategy for software debt? It is all too easy to overlook software, especially if that software supplements an experience but is not your core system of record. Most organizations don’t realize that all their software is constantly collecting technical debt and that a hidden business cost (in addition to any service agreements) may be growing unrecognized. 

Common Causes of Software Debt

Software entropy: Like the second law of thermodynamics, this principle states that a closed system’s disorder cannot be reduced, it can only remain unchanged or increase. As a system is modified, its disorder, or entropy, tends to increase.  Over the years, businesses add new requirements to their software systems, change features, move to new equipment, etc. These changes increase the technical debt their software is accumulating.   

Software brittleness: When a software project begins, it is at its most malleable.  The system hasn’t collected a lot of data. Not all the features have been used repeatedly.  The users of the system accept flaws.  There are less users.  Much like metal, software becomes brittle over time simply because it is used often. Any attempted changes need to be considered carefully and carry a greater risk. 

Software rot: Software rot is something we often encounter but is one of the hardest causes for businesses to understand. Software rot is a slow deterioration of software performance over time. Its diminishing responsiveness will eventually lead to the software becoming faulty or unusable. 

The most common cause of software rot is environment change. When software is created, it is created with certain assumptions but can’t predict the future. For example, software is often tested with a sample set of test data. That set of test data may be quite large and try to simulate a fully operational system; however, the assumptions around the test data may not match how the system grows. For example, a business may plan for millions of customers with single item orders but find, instead, that they receive thousands of customers with many line orders. This exposes untested areas of the software, and the software’s architecture is faulty in handling the data set. Common things that collect large amounts of data, like too many items in a filtered search or a complex report, reveal the unused code and software rot. Unfortunately, these realities may not be exposed for many years and isn’t a bug since the software does function based on the assumptions at the time of development. 

Ok, what do I do with technical debt regarding my software? 

The simple answer is to create a strategy and recognize a budget. The core to a good strategy is understanding what software is most important to your company. (What software will make a business impact if it fails? What software covers a lot of surface area within your organization?) Then, develop a maintenance or replacement strategy for that software.  

A common strategy for software technical debt is care and maintenance, like we do for hardware. Software people like our own terminology though, so we call it code refactoring. Code refactoring is the activity of restructuring existing computer code without changing software’s behavior or features. Refactoring improves code readability and reduces complexity.  This will improve the software’s maintainability and create a better internal architecture.  The goal is to get in a pattern of refactoring as part of your processes and strategy, so you'll find that it is easier to extend and maintain code rather than collecting ‘interest’ in your technical debt. 

Another strategy for software technical debt is planned obsolesce. Planned obsolescence is the recognition that something has a finite amount of usefulness before replacement. Often, software technology is moving so fast and your business is changing so rapidly, that this strategy can be cost effective over code refactoring.  Planned obsolescence isn’t for everyone but is sometimes forgotten as a good strategy.

In each strategy, you typically see a 3 to 5-year lifecycle where either code refactoring or replacement is needed for many of today’s software systems.

You may be thinking that you need to also change your software development processes to account for this new world of technical debt, but that is an article for another day.