Spiria logo

Technical debt: what it is, and how to control it

Social networks are rife with stories illustrating how hiring the cheapest company or lowest bidder to perform a professional service ended up costing more over the long run. This holds true in the software world. Just as with construction work (foundations, plumbing, electricity, etc.), cheap is not good.

At a time when more and more companies base their business model on creating or implementing a software platform, the issue of how durable your investment in development is will be is crucial. To optimize the durability of your investment, keep in mind the concept of “technical debt” when planning your software platform.

Technical debt is a metaphor coined by Ward Cunningham, inventor of wiki, father of extreme programming and one of the signatories of the famous Agile Manifesto. Technical debt means that shortcuts or compromises at the development stage, whether due to time or budgetary constraints, sloppiness or even ignorance, rack up a “debt” that will have to be paid off at some point in the future. This takes into account the idea that the value of code tends to evolves over time according to a downward trend. While some technical debt is inevitable, it can be controlled to minimize its financial impact over the life of the platform.

The consequences of accumulating heavy technical debt can be disastrous, making it impossible to upgrade a solution or adapt it to a new platform. The use of technologies or versions that are no longer supported can make the solution vulnerable to security threats. Technical debt is always bad, since it raises development costs, handicaps a company’s growth, complicates administration, stretches liquidity and causes headaches for managers. Code quality is an important factor in platform value, and often has an impact on a company’s performance.

For example, code that is poorly documented or that doesn’t follow industry best practices is all but impossible to migrate when taking over development or switching to a new development partner. These transfers can happen at any time and repeatedly over the life of a software system, carrying a hefty price tag. Hence the importance of asking questions about best practices when choosing your development partner.

What if your project hasn’t aged well?

If your software platform was developed in-house, you’ll need to hire a development company to perform an audit on the code. Then, you’ll probably have to prioritize and plan changes to your code based on their findings and recommendations. In order to do this, you’ll have to gain a thorough understanding of the problems found and the impact of outdated or poor-quality code. Obviously, just like financial debt, fixing code is worthwhile only if the benefits outweigh the cost, and if that cost can be amortized over time.

How can you avoid the problem altogether?

In most cases, you’re better off spending a little more up front to ensure lasting development. Here are four recommendations:

  1. Choose a professional team or company that will take pains to gain a good understanding of your short, medium and long-term vision and business objectives from the outset, in order to select the technologies that will support this evolution.
  2. Make sure your code is properly documented to reduce maintenance and support costs while ensuring its transferability.
  3. Automated testing can help you detect any losses in the integrity and accuracy of your software features.
  4. Finally, continuous bug management and the implementation of DevOps techniques will allow you to keep tabs on your software system’s health and act according to your strategic priorities

In conclusion

Technical debt management is part and parcel of durability and responsible investment. There are many solutions to help lower debt and plan out a more durable technological ecosystem. Perhaps the most important thing is to choose your team or development partner according to their ability to manage this challenge.

This entry was posted in Method and best practices
by Jean-François R. Gagné.
Share this article