Is Technical Debt Always Bad?

Home » Software Development » Is Technical Debt Always Bad?

Debt can be a loaded word. But is all debt bad? In the world of finance debt can be a useful tool to scale businesses or access opportunities that would otherwise be unobtainable. The same is true in tech. Accruing technical debt can see Minimal Viable Products and product-market fit obtained faster while keeping initial costs and development time lower. BUT, just like in finance, technical debt needs to be planned and managed from the start or you could end up in a world of pain.

First off, what exactly is “technical debt”? And what contributes to its accrual?

What is technical debt?

You can think of technical debt as the price you pay for getting software products and features released as fast and cheap as possible. Some of the main causes are:

Lack of proper planning and system design: whether through negligence, inexperience or circumstance, proper planning and system design and a lack of long-term thinking can lead to extensive code re-work or refactoring and excessive bugs/technical issues post deployment;

Poor code quality: as above, this is mostly caused by human factors and a lack of coding standards, poor or non-existent Quality Assurance procedures, or lack of experienced or accountable technical personnel;

Changing requirements: shifting goalposts can lead to thousands of lines of code that took months to write be thrown out or refactored almost entirely to make subtle changes barely discernible to the end-user. This can demoralise software developers and lead to rushed, poor quality work. A civil engineer would be devastated if half the tower he spent months/years designing and building was knocked down due to a minor aesthetic change;

Tight timelines and budgets: this is arguably the #1 cause of technical debt. Product Owners, Project Managers, Business Owners and end-users demand fast work for low prices. The amount of work in developing complex requirements into stable, scalable and functional applications can be underestimated by those not at the coalface of software development. See the diagram below for more details:

Warning signs of tech debt in your software products

If you’re worried about unmitigated tech debt in your applications, there are a few red flags you can look out for. If you’re not from a technical background you might need a qualified, independent third-party to help you understand the inner workings of your project.

Code that is difficult to read: Codebases that are poorly designed, written, structured and/or documented, can be difficult for developers to understand. Identifying related code that will cause features to “break” when other components are refactored can also be akin to finding a needle in a haystack;
Inordinate number of bugs or defects: Bugs and defects are to be expected, but when they are constantly popping up (especially as new features are implemented or code refactored) it can be a clear sign that the code is poorly designed or implemented, and that technical debt has accumulated;
Demotivation or “technical exhaustion” among the development team: Engineering teams feeling overwhelmed or “burned out” due to the difficulty of working with the codebase, it could be a sign of excessive technical debt making progress excessively difficult and frustrating;
A preference for short cuts: If the development team is knowingly relying on workaround solutions to address problems rather than addressing the root cause, it could be an indicator of technical debt.

Is tech debt in software development project always bad?

It may seem like doom and gloom, but is technical debt always a bad thing? No, not if it’s handled correctly. As with the financial example at the start of this article, if tech debt accrual is planned and managed effectively from the start it can be a useful tool to get users what they need as fast as possible.

In some cases, it may be necessary to take on technical debt in order to meet deadlines or to quickly get a product to market while avoiding or mitigating the potential negative consequences. Unaddressed technical debt can lead to code that is difficult to understand and maintain, which can slow down development and increase the number of defects and bugs. It can also make it harder to add new features or make changes to the codebase, which can limit the flexibility and agility of the project.

How can tech debt be managed?

Ultimately, the key is to carefully weigh the costs and benefits of taking on tech debt, and to regularly address it to avoid it becoming a burden on the project.

Regularly pay down the debt: Incorporating time and resources for addressing technical debt into the development schedule can help ensure that it is regularly addressed, rather than allowing it to accumulate. This can include refactoring (restructuring) code and can be done after crucial deadlines are met.
Setting stringent coding & Quality Assurance standards: High internal standards, regular code reviews, and well defined structure and architecture can help avoid the creation and accumulation of technical debt. Setting the standards and structure can also speed up development time by reducing confusion amongst developers. Effective and empowered Quality Assurance Management can mitigate the risk of technical debt accruing beyond manageable standards. .
Use version control: Using version control, such as Git, can help track changes to the codebase and make it easier to revert to a previous version if necessary.
Avoid scope creep: Keeping scope creep in check can help avoid the need to make significant changes to the codebase after development has already begun. This can be easier said than done as everyone can have different views on what is and what isn’t within scope.