Is Technical Debt the Monster it is Made Out to Be?

Published Date

As a business owner or developer, have you been involved in a project where a simple feature change or even a bug fix has taken weeks to resolve and often brought with it other problems? That is technical debt in action. But is technical debt to be considered a code monster lurking in your system ready to terrorize you?

There are times when it is acceptable to have technical debt. However, it is just as important to recognize how to reduce technical debt for continued product health. After all, going into debt to buy a house is perfectly fine if you know how to pay the loan back at the earliest.

When is technical debt acceptable?

Technical debt is often a result of taking shortcuts during project development, mainly because of time constraints. You may feel then, that technical debt is a monster that will hinder growth. But there are a few instances where technical debt is acceptable and these are

  • If the organization wants a competitive edge by releasing the product quickly. The project owner then makes a plan for refactoring the code at the earliest
  • If it is a new idea, and developing a prototype to see if it will be viable in the market. This is a deliberate technical debt where speed to market takes priority rather than clean code.

Don’t fear technical debt but understand how to address it

The general belief is that technical debt is caused by poorly or hastily written code. The reality is that it is not always the case.

Going back to the house analogy to explain why technical debt is inherent in even the best-written code. It does not matter how well you have constructed your house, there will come a time when the roof will need fixing, the interiors repainted or the plumbing repaired. There is always wear and tear that comes inevitably with time.

Code can start out ticking all the boxes on quality but a component or system can slowly bec