Software Quality Assessment based on Lifecycle Expectations

Étiquette : SQALE

The benefits of the Technical Debt concept

Article mis en avant

Technical Debt is a powerful metaphor which is used more and more often at all levels of an IT organization. The concept has been defined and strongly supported by the agile community, but it applies to all kind of developments and all types of languages. Whatever the unit you use for measuring the debt (dollars, hours, work units etc.), the figures are easy to understand and to handle.  It tells you how far you are to your coding standard compliance. This way of measuring code quality provides at least the following benefits:

  • It provides an « easy to understand » and common language for all teams and their management.
  • It can be easily compared with other familiar measures like delay and costs.
  • It allows monitoring  trends and performing comparisons.

In addition to that you get the benefits of a « true » measure:

  • It is objective. The amount of technical debt could be measured (or at least estimated) by automated analysis tools and so would not depend on subjective opinion.
  • It is reproducible . Provided that you communicate your list of « what incurs Technical debt » in your context and the recipe to transform findings into the estimated value, the evaluation process is reproducible over time, over projects, over organizations.
  • It is a sensitive measure, Even you are facing a huge amount of technical debt (let’s say 1,000 days) Whatever improvement you perform into your code, let’ say you spend 2 hours to refactor a too complex method, the new evaluation will be something like 999,6 days !

Because all of this, technical debt is a new measurement paradigm. When technical debt management is well implemented and deployed it becomes a powerful tool to support decisions and improve software quality.

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