Software Quality Assessment based on Lifecycle Expectations

Étiquette : SQALE

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?

Testimony on SQALE

From Dr Israel Gat – Cutter Consortium Fellow and Director, Agile Practice – who uses SQALE for performing Technical Debt Assessments.

Context over Content

“Context over Content” is my mantra in just about every consulting engagement I carry out these days. You will literally hear me tell my clients something like “Values, principles and practices are, of course, extremely important. However, as far as this engagement is concerned the only thing that really matter is how we will jointly apply them in your specific context – your needs, your resources, your predicaments, and your constraints.” In the domain of software quality evaluation, I find SQALE – Software Quality Assessment based on Life Cycle Expectations – a great tool for implementing my mantra. It interprets source code analysis in terms of what really matters in the specific client environment. In so doing, it transforms an overwhelming set of measurement data to actionable insights which are meaningful at multiple levels of the firm.”

Israel Gat, January 2012

Fièrement propulsé par WordPress & Thème par Anders Norén