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. However, it’s far more complex than that.
Technical debt can be measured in several different 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.”
A rush to build is a common cause of tech debt
“When you don’t spend enough time thinking about a feature or designing it before you just start coding, it can lead to technical debt,” says Jackson. “If you rush code, then you get it 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.”
Rushing to build is often prompted by things like monetary gain or market competition. In the case of startups, Jackson says this is especially prevalent because they must first build something just to present to investors. He says the rush then continues because even if the startup gets the buy in, they pretty much lose if they’re not first to market.
Poor choice of technologies is another common cause
“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.”
Jackson says lack of evaluation or knowledge of how the solution will scale is often how poor technology choices are made. In many cases, 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. Then as the product scales, requiring increased capacity and functionality along the way, technical debt continuously adds up. If left unmanaged, the technology will eventually be unable to handle the solution.
A breakdown in communication can also 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 intended. The software then keeps evolving into something else entirely, which must eventually be addressed.
Keys to managing tech debt
Technical debt doesn’t usually have any customer facing effect. Therefore, while it can feel like the software development team is accomplishing a lot when 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 and the need to manage it properly. But 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.”
Software development teams should ask these questions when working to manage tech debt effectively:
- What led to the buildup of debt? This will help prevent the product from getting back into tech debt after it has been cleaned up.
- What will the result of cleaning up the technical debt be? Will it be an increase in performance? Will it allow for easier maintainability thus saving development time in the future? 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.
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.