Technical Debt: Case Studies and Lessons Learned

Technical debt: Case studies and Lessons Learned

In the fast-paced world of [software development](/services/software development) time and resources are often scarce goods. In order to comply with deadlines and bring new features to the market quickly, abbreviations are often used. These compromises in code quality and architecture are called technical debt. Similar to financial debts, they can bring advantages in the short term, but in the long term lead to high “interests” in the form of slowed development, increased maintenance costs and in the worst case to a complete project shutdown. But what exactly hides behind this concept and how can companies learn to manage their technical debt effectively?

What are technical debts?

The term “technical debt”, coined by software developer Ward Cunningham, is a metaphor that describes the consequences of suboptimal technical decisions. Every minute that is invested in “not quite correct” code counts as interest on this debt. If this debt is not violated, the interest rate burden can paralyze an entire development organisation.

Technical debt is not per se negative. Sometimes it is a conscious strategic decision to publish a function faster and to neglect the code quality for the first time to achieve a market advantage. It becomes problematic if these debts grow uncontrolled and are not actively dismantled.

Types of technical debt

Expert Martin Fowler has categorized technical debts in a quadrant model that distinguishes between conscious and accidental debts as well as between obscure and reckless debts. This classification helps teams to better understand the causes of their technical debt.

| | Regardless | | | :--- | :-- | :-- | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ** **We have no time for design.” | “We need to deliver quickly and take care of the consequences later.” | ** Of course | “What is a layer architecture?” | “Now we know what to do.” |

This categorisation makes it clear that technical debt is not always based on negligence. They are often the result of a learning process or a conscious balancing of priorities.

Case studies: The expensive consequences of technical debt

The effects of uncontrolled technical debt can be devastating, as some well-known examples show from practice.

Knight Capital Group: The 440 million dollar bug

In 2012, the Knight Capital Group lost 440 million US dollars through a software error within only 45 minutes. The cause was a faulty provision of new code on old, unused servers. This case is a dramatic example of how inadequate tests and outdated code can lead to catastrophic financial losses.

The Last of Legacy Systems in Ba