To understand technical debt, we first have to remind ourselves of the principles of financial debt. Financial debt lets you have the benefit now at the cost of making regular interest payments later.

The only way to stop the interest payments is to pay back the principal amount. So, it is a well-known thing that taking on financial debt now comes with some obligations later on, and these obligations need to be carefully evaluated before taking on financial debt. Debt is not bad; it is how you used it that matters.

What is Technical Debt?

Technical debt refers to hacks that software development teams do for short-term benefits which lead to poor internal software quality or design. The interest paid on technical debt is the amount of effort that needs to be undertaken in order to remove these hacks and implement the right thing. Technical debt drastically reduces the speed with which new features can be added. If technical debt is left to accumulate long enough it becomes nearly impossible to add new features.

Poorly written software = technical debt.

Causes of Technical Debt

Why do teams take on technical debt when it is certain that there will be consequences later on? Well, here are some possible reasons for this.

Business Pressure

Software development teams have to deal with the complexities of software development, they also have to deal with the pressure from business to get features released quickly. Most times, building features the right way takes longer than business is willing to consider. Features typically have a 3-hours-to-build, 3-days-to-build or 3-weeks-to-build version. Your guess is as good as mine, teams will opt for the 3-hour version when faced with pressure from business. Most times the 3-hour version is the hacky version.

Poor Developer Quality

Poorly written software = technical debt. Disregard for code best practices, sloppy comments, vague variable names, and ambiguous methods are some of the things that make code very hard to understand. Code that can’t be understood is very hard to maintain even for the original author of the code.

Poor Software Design

Poorly written code happens at the implementation level but technical debt can also be incurred at the software design level. Software design is important but design that fails to evolve becomes a bottleneck for improvement later on.

The True Cost of Technical Debt

One of the major implications of technical debt is it slows down software development sooner than teams expect. The reason for this is because technical debt makes it hard to really understand what is going on in the codebase and changes often lead to bugs that no one understands. The effort required to undo the wrong approach and do the right thing can be daunting, and if business pressure was the original cause of the technical debt, it becomes virtually impossible to set time aside to undo it.

The key to taking on healthy technical debt is to evaluate the trade-offs now and in the future.

How to Think About Technical Debt

Technical debt comes in many forms and not all technical debt is bad. Just like financial debt, it is how you use the debt that matters. The kind of technical debt that is generally considered bad is the type that revolves around poor code quality. Teams should avoid hacks in code that reduce its quality.

Technical debt that is delibrately taken on for strategic reasons can be of benefit to a software development team. For example, when faced with a tight deadline for releasing a new version of a web app, the team can decide to use generic error handling and logging in order to save some time. After the release, the team can then define a proper way to handle errors that occur and log them appropriately. This kind of technical debt helps but the danger of forgetting to come back to fix it has to be avoided, otherwise it will become hard to determine where errors come from later on.

The key to taking on healthy technical debt is to evaluate the trade-offs now and in the future in terms of the effort it will take to do the right thing against the benefits of doing the hack now. The effort needed in undoing the hack has to also be taken into consideration.

Summary

One of the characteristics of high qualify code is the ability to easily understand it nad make changes whether it was written by one person or a team of developers. Code should be written with the ease of future change in mind. “How can I make this code easier for someone, including myself, to understand it and make changes in the future?”. Once code is written the rest of its lifetime is spent in maintenance mode. Technical debt can prevent teams from enjoying the benefits of high quality code. At the same time, teams can use it to their advantage as long they weigh the trade-offs and keep track of exactly what needs to be done to implement the right thing.

Additional Resources

Ward Cunningham is credited with the first use of the term technical debt as documented here. He is also the inventor of wiki.