Archives par étiquette : Analysis

Obsolescence and Technical Debt

I have read many blogs and articles on Technical Debt. I also participated in exciting events on the topic. They are at least 2 major and positive messages that are always raised:

  • The code quality is very important and all projects, all organisations should monitor it.
  • The Technical Debt metaphor is a simple but smart way to monitor this code quality in a way that everybody in the hierarchy can understand.

I have a concern about what should be included in Technical Debt.

If, at a point in time, we analyse the source code of an application, we will for sure, have findings, room for improvement. Do we have to count everything as Technical Debt? It sounds logical, but if we take a step back, it seems to me that we should differentiate two types of findings.

1st Category: Findings related to violations of good coding/implementation practices, violations of architecture constraints etc. I will put in this category and as example:

  • Copy and paste
  • Over complex methods
  • Violation of architecture layers
  • Cyclic dependencies
  • Naming convention
  • Presentation convention

2nd Category: Findings associated to the fact that since the software has been delivered there has been some technology progress. New ways/tools are now available, allowing better stability, changeability, performance etc. Examples that come to mind are:

  • ESB
  • New framework (or new version)
  • New library (or new version)

From my point of view, the second category should not be counted in Technical Debt, it is just obsolescence.

Obsolescence  should be used for managing the application, governing a portfolio. In the balance sheet, this figure will have the same negative effect as the Technical Debt. But to be more precise, it should be in specific cell dedicated to evaluating the depreciation of the application not in a “debt” cell.

If we go back to the original quote from Ward Cunningham about Technical Debt, Technical Debt comes from the “not right code”. That means that it comes from violations of source code versus requirements. Ward does not include any additional root causes.

If we include into Technical Debt findings with root causes linked only to technical progress and obsolescence, Technical Debt will increase over time without any change to the code and we will attribute unfair debt to developers.

Does obsolescence count as Technical Debt?

What about differentiating Technical Debt and Technical Obsolescence?

What’s your opinion?