Technical debt is the cost of doing additional work caused by choosing an easy, limited or sub-optimal solution now rather than using a better approach that would take longer or cost more money.
The term technical debt refers to the work that is necessary to do sometime in the future to rewrite poorly written or incomplete code to remove deficiencies. The more technical debt your application has, the more opportunities exist for spending money and effort to bring the code up to an acceptable level of quality and professionalism.
However, some amount of technical debt is inevitable in modern digital applications. In fact, completely avoiding technical debt is an anti-pattern in modern application development. The entire concept of Agile development and the use of a minimum viable product (MVP) involves the embrace of technical debt and a way of incorporating the management of technical debt into our software development process.
In a previous article, I talked about how to manage technical debt in a cloud-native application. But how does technical debt grow in the first place?
Technical debt is a measure of imperfection, so any application that is not “perfect” has some technical debt. In practice, this applies to all applications built and used by any company. Rather than trying to avoid technical debt, the best practice is to learn from it and manage it to make your application effectively maintainable. The goal isn’t to avoid technical debt. Rather, the goal is to avoid unmanaged technical debt.
So, where does unmanaged technical debt come from? While there are many sources, one common source of excess unmanaged technical debt is application complexity. The more complex your application is, the more unmanaged technical debt you will likely have.
Technical debt and complexity go hand-in-hand. While technical debt is not a complete picture of application complexity, the growth of technical debt is tied very closely to the growth of application complexity.
As your application becomes more complex, it becomes brittle and hard to work with. This brittleness leads to problems and issues, which leads to failures and customer dissatisfaction. This instability—a direct result of complexity—is the leading driver of unmanaged technical debt.
Complex Applications Become Brittle
The problem with complexity is relatively straightforward. A complex application is subject to having minor issues quickly escalate into major problems, while a less complex application is less affected by smaller problems. In fact, the more complex the application, the smaller the problem that is required to bring the entire application down.
This is because most applications operate in a well of stability, which tends to keep the application operating at its best. This well of stability provides positive reinforcements to our application, which keeps our application centered and operating normally.
A brittle and complex application, however, does not have these positive reinforcements, and hence the well of stability turns into more of a hill of instability.
In this figure, even a light push of the ball can cause the hill to reinforce the push and drive the ball further down the hill. Similarly, a brittle application can take a relatively small issue and blow it up out of proportion until it becomes a major application problem—hence, a major business issue.
Most stable, modern applications operate in a solid well of stability. Yet, complexity tends to invert the well into a hill, causing greater application instability.
The Instability of Unmanaged Technical Debt
Application stability can keep your application operational, but unmanaged technical debt caused by complexity is a large driver for application instability.
The more complexity an application has, the higher up the hill and the less stable the application is in general. The less complex, the lower the hill (well) and the more stable the application.
Hence, managing complexity in a large, modern digital application is a critical aspect of managing technical debt and keeping your application stable.
