At its core, technical debt in software development is the implied cost of additional rework caused by choosing an easier solution now, instead of choosing a better approach that takes longer overall. Tech debt can be measured in several ways, including technical problems, scalability issues, productivity loss, and financial cost.
John Jackson, Chief Technical Officer at Bit-Wizards, says you can think of tech debt like construction.
“It’s like if you’re building a deck. If you take your time, you sand everything, you stain the wood, and you make sure it has the proper finish, it’s going to last a long time and you won’t have a lot of issues. Alternatively, if you rush building the deck because you want it done by the end of the week, that’s great, but you probably didn’t put a lot of the necessary legwork in. Now it’s going to have a lot of issues that need to be fixed, maintained, and could even get worse.”
3 common causes of technical debt
1. A rush to build
A rush to build software is often prompted by things like monetary gain or market competition.
“When you don’t spend enough time thinking about a feature or its design before you start to code, it can lead to technical debt,” says Jackson. “If you rush code, then you might get the software out the door, but you will always have problems with it. Then, you’re spending all your time fixing those problems instead of producing more productive work.”
In the case of startups, Jackson says a rush to build is fairly common because developers must first put something together just to present to investors. He says the hurry then continues because even if the startup gets the buy in, they pretty much lose if they’re not first to market.
2. Poor choice of technologies
Jackson says lack of evaluation or knowledge of how the software will scale is often how poor technology choices are made.
“When you’re building things, like in the case of MySpace, they chose PHP,” says Jackson. “But that stopped them from being able to do anything after a certain point. PHP was good for building quickly, but as their solution got bigger and bigger, everything got super hard to maintain. So, eventually, MySpace just couldn’t build anymore and went out of business because of it.”
In many cases, Jackson says companies don’t take the time to map out the future of a solution carefully enough in the beginning, leading to uninformed or incorrect technological decisions along the way. Then, as the product scales, the software requires increased capacity and functionality, so technical debt continuously adds up. If left unmanaged, the technology itself won’t be able to handle the solution eventually.
3. A breakdown in communication
Finally, miscommunications can easily lead to tech debt.
“Sometimes, the people that come up with the software or feature don’t communicate well enough to the people building it, so they have two different expectations in mind the whole time,” says Jackson. “So, when developers come back with what they thought you wanted, it’s not at all what you want.”
In this case, the tech debt accumulates when developers leave the solution as is, rather than reworking it as it was intended. The software then keeps evolving into something else entirely, which must eventually be addressed.
Keys to managing tech debt
Software development teams should ask the following questions when working to manage tech debt effectively:
- What led to the buildup of tech debt? This will help prevent the product from getting back into tech debt after it has been cleaned up.
- What will result from cleaning up the tech debt? Maybe it will lead to an increase in performance or allow for easier maintainability, saving future development time. These will both be important considerations when presenting a plan to stakeholders for allocating time and resources to the cleanup.
- Can you perform the cleanup without preventing or conflicting with ongoing enhancements? Often, technical debt cleanup can require massive underlying changes. In this case, timing and coordination become especially important to effectively manage it.
Technical debt doesn’t usually have any customer or user-facing effect. So, while it can feel like the software development team is accomplishing a lot while addressing it, to the customer, it can feel like the product has stagnated. This is why a common roadblock to addressing tech debt is convincing company leadership that it’s worth it.
In the case of Bit-Wizards, the CEO and COO were once software developers, so Jackson says they fully understand the risks of tech debt, how to manage it, and the need to reduce it. However, for many organizations, Jackson says this isn’t the case. He says this is when it’s useful to compare the fallout of tech debt to financial debt.
“If you don’t pay off a certain amount of the interest, it just keeps growing and growing until interest is untenable, and you basically can’t get anything done. Eventually, it can kill you off. That’s what happened with MySpace.”
Presenting the technical debt ratio (TDR) to the leadership team can be an effective way to get buy-in for fixes. TDR is a metric that estimates the future cost of tech debt by comparing what it costs to fix the problems against the total cost to build the project. This calculation can include money, labor, and hours.
Why do you need to manage tech debt?
Tech debt can negatively impact efficiency, employee morale, and the product or service as a whole.
“If you’re always patching things, you’re not getting new things done, so new work suffers and you’re not innovating and producing,” says Jackson. “It can also affect your team because now they’re not growing and learning new skills because you’re stuck working on old stuff.”
At the end of the day, software development teams must balance the time they spend cleaning up tech debt with continuing to innovate and improve the product. It’s a constant balance, but a necessary one, which can be made easier with proper management.