Invisible Software Development Costs Caused by Technical Debt

When a software development team estimates how many hours a fix or feature will be, there’s one factor they have to take into account that many stakeholders may not know about or understand: technical debt.

“Technical debt” is a term that describes existing inefficiencies in a codebase that have accrued over the life of the project. Sometimes these inefficiencies could be caused by shortcuts a development team took, but others are simply an unavoidable result of the software development process.

For example, a development team works with a childhood education company to build an app serving educational games to young users. The development team also builds a content management system (CMS) that allows the company to upload new games, set the appropriate age range for each game, and add in descriptive text.

At some point, the company decides they want to add video demos for a handful of games to see how their users respond, but they aren’t ready to invest in building out video-adding functionality to their CMS yet. The developers hard-code these new videos into the app. The games with videos perform well, and the company decides that every game should have a video, which means they want to add a section for demo videos to their CMS. The development team updates the CMS to offer this added functionality, but they will also need to refactor the code to replace the original hard-coded videos with videos that are now pulled from the CMS.

In this example, the company and the developers made optimal choices, but technical debt accrued anyhow. Here the amount of technical debt was quite small, but there are times where technical debt can become expansive.

Regardless of its scope or cause, technical debt increases the number of hours it takes to implement new features, inflating costs and extending timelines. If left unresolved, it contributes bugs to the system on an ongoing basis. And when it accrues, technical debt can demoralize your development team, even up to the point where if it’s bad enough, developers may be unwilling to take your project on.

How does technical debt happen?

Technical debt usually happens in one of two ways. The good news is that regardless of how it comes about, anticipation and practicing good code hygiene can keep it under control.

The first way technical debt accrues is unavoidable, because it’s the result of how software is built.

When beginning a software project, it’s rarely possible to perfectly describe the exact details of each and every aspect of the project. Think of it like a police sketch: you can tell the artist hair color, eye color, face shape, if there’s facial hair, what kind of jaw structure, etc. but in many cases the artist will be inferring certain details, such as average earlobe length.

The standard set of assumptions the artist makes based on unspecified detail is necessary to prevent the sketching process from extending ad infinitum, but it does mean that if down the road you identify some aspect that needs to change–say you realize your subject should have longer than average earlobes–that change will need to be made.

In this analogy, technical debt is what happens when the artist (developer) draws new, longer earlobes on request but doesn’t erase the original shorter earlobes. Why? Because this is where the analogy falls flat: erasing an earlobe is straightforward, but developers can’t simply erase code. That would break the software. They need to rewrite it, and rewriting it takes time, and they are often working under deadlines to implement new features.

Under ideal circumstances, developers will be given the extra time they need after a release to go back and “refactor” the codebase so that everything is clean and orderly. If they don’t have that time, however, the technical debt begins to accrue. And once the technical debt accrues, the work that follows will often take longer and be more complex–and more expensive.

In addition to this process, there are also new features that get added as a project matures. To go back to our police sketch analogy, it’s as if you were to say, once the sketch was done, “now give him a hat.” Parts of the picture necessarily need to be redrawn to give the subject a hat. The same is true with code.

The other way technical debt accrues is if developers take shortcuts. A developer may opt to take a shortcut if they are not thorough and conscientious, or they may have to take a shortcut out of necessity to meet a deadline. There are many times where it’s actually in a business’s best interest for the developer to take a shortcut to meet a deadline, and as a result most senior developers are constantly in a dance with debt. In these cases, it’s again important to give the developer time to go back and refactor the codebase.

Many times, development teams may not bother to try to explain to you that they are working with technical debt, since it’s a concept that’s unfamiliar to most outside the world of software development. Because of this it can be worth asking your team: “Is technical debt slowing this project down?” or “Would it be worthwhile to take time to refactor the codebase to improve efficiency?”

How technical debt impacts projects

When technical debt is left unchecked, it can compound and become more complex over time. This means that the longer you wait to address it, the more time and resources you'll need to fix it. In some cases, the amount of time and effort required to address technical debt can take away from other important tasks and delay the release of new features.

In addition to the time and effort involved in addressing technical debt, there is also the issue of reduced efficiency. When technical debt is present, developers may need to spend more time working around it, which can slow down their overall productivity. This can stretch out timelines, which can have a negative impact on the success of your project. The best way to address this is to allow the developers to resolve the technical debt first, and then proceed forward with greater efficiency.

If left unresolved, technical debt can also introduce bugs. This can lead to decreased user satisfaction and loyalty. If your software is plagued by bugs and other issues, users are likely to become frustrated and may choose to switch to a competitor's product, resulting in lost revenue.

Finally, technical debt can also lead to increased maintenance costs down the road. When technical debt is present, it can be more difficult to maintain and update your software, which can lead to increased costs over time. These costs can include everything from additional developer time to increased hosting and infrastructure expenses.

Our recommended approach to technical debt

We’ve found that the best approach to dealing with technical debt is a one-two punch:

• Always keep the big picture plan in perspective and limit the number of corners you require your developers to cut when possible. This will reduce the amount of technical debt generated.
• Allocate time for your development team to resolve technical debt as they need to in order to maximize their efficiency.

Since it’s not possible to reduce technical debt to zero, the most sustainable approach is to minimize it when possible and address it when it becomes an issue. By taking the time to resolve technical debt, you can improve the long-term efficiency and success of your project and ensure that it remains competitive and successful in the marketplace.