Technical Debt #2: Where it comes from

by Andrea Maioli on 01/22/2013

Last week we talked about technical debt in software development, defining it as part of the work that needs to be done to complete the changes that we know about now but that we can’t or don’t want to make today, and which will have to be tweaked or completed later. In this article, we’ll see where Technical Debt comes from and which working practices tend to generate the most. To do that, we’ll use an “indirect” proof, as mathematicians would say. Is it possible to have an organizational method for software development that doesn’t create technical debt? In theory, the answer is yes. All you need is:

  1. All the time and resources necessary to analyze and fully understand the process you need to computerize (debt due to lack of analysis).
  2. All the time and resources necessary to write the code so that it is perfectly consistent with the best practices of the various technologies used (debt due to lack of best practices).
  3. All the time and resources necessary to change existing code so that it’s seamlessly integrated with the newly created code. This also requires a perfect understanding of the existing code (debt due to lack of integration).
  4. All the time and resources necessary to create a suite of automatic and integration tests for testing the various features of the written code one by one (debt due to lack of a suite of tests).
  5. All the time and resources necessary to write the technical support documentation for future changes to the codebase (debt due to lack of technical documentation).

Reading this list, it’s pretty clear that in practice it’s nearly impossible to avoid creating a large amount of technical debt. In particular, it grows in step with the complexity of the software because of point 3, and it also increases as technologies change because of point 2. The problem that grows technical debt the most lies in small changes to very complex software. In fact in this situation, you can’t justify the amount of work required to make the change without creating debt, so you’re left making so-called band-aid fixes, which you simply hope will stick, even in the future. In the next post we’ll look into how technical debt can be managed, and how relational programming in Instant Developer can be a formidable tool in achieving this goal. In the meantime, why not try to get an idea of how much technical debt you’ve accumulated?

In this series:

Image: On Space Time Foam by Tomás Saraceno

Leave a Comment

Previous post:

Next post: