More details

Download the accepted paper.

Download the presentation.

The SQALE Quality Model identifies quality characteristics and put them in a chronological order. It appears that the first one at the bottom is Testability.

This means that even before you look at the reliability of your code, its performance, its safety, its maintainability by third parties etc… You must first look at its testability and fulfill the associated requirements.
If your code is not testable (that means it is too much complex, too much coupled …), you will not be able to test it adequately before delivery. You won’t be able to check and improve its reliability and safety.  Also later, when you will make changes and corrective maintenance on your application, you won’t be able to test and check correctly your work.

This leads to the conclusion that testability is the foundation upon which all the other quality characteristics rely. This does not appear in standards such as ISO 25010 and it does not help to raise the importance of this characteristic.

Because all other abilities depend on testability, if you want to improve the overall quality of an application, you must start by improving its testability. That means refactoring its architecture and its internal structure in order to make it completely testable.

What is quite surprising (and also beneficial) is the fact that this quite technical concept is also used and supported by middle and upper managers. I have already mentioned within a previous post that the CIO of a very large bank (30,000 + developers) monitors on a quarterly basis, and with the SQALE method, the technical debt of its complete portfolio.

There are probably many reasons for this growing interest and each manager will have his own. Here are the reasons, which in my opinion, are the most common.

1. Technical debt is an objective measure of quality. In fact it measures “non-quality” and tells you how far (in terms of days, $…) you are from complying with your “right code” definition. This is a very simple concept. It is easy to understand and facilitates communication.
2. Consolidation is easy: Consolidation is performed by simple summation. If you have an estimation of the technical debt of each of your applications, then it is easy to get the technical debt for each of your domains and for your complete portfolio.  As an example, this is what is automatically performed by the combination of the views and SQALE plugin of the Sonar platform. If your static analysis does not do it for you, it’s still easy to consolidate the numbers within Excel.
3. Technical debt density has a useful meaning. It’s easy to calculate the technical debt density of an application or a domain etc. You just need to divide the technical debt of an item by its size (If your analysis tool does not support this feature, again, Excel will do it for you). This will allow you to compare quality of items of different size. You will be able to compare projects developed (or maintained) by different subcontractors or in different locations.
4. Technical debt is estimated in days or dollars, which can easily be compared with other project or portfolio management data. It is meaningful to compare technical debt to other measures like remaining schedule or budget allocated on a project. Technical debt can be correlated to such project data (and many others) providing support to managerial decisions.

Technical debt is probably the first code related measure which fulfills the measurement needs of managers; it also fits well into their favorite tool: Excel. Their interest for this measure is not a temporary fashion. Technical debt is becoming part of many management dashboards and will support more and more portfolio management decisions.

Your strategic decisions will depend on the precision of your Technical Debt estimations. Make sure that your estimation model is calibrated to your context.

In this case, we must ask ourselves whether the source code of the project in question does not contain too much technical debt inherited from years of maintenance. If the inherited debt is too high, it is likely that it does not lend itself to an agile maintenance mode. How do I know which applications will be eligible to a maintenance type change, and those who do not?

We will see that the SQALE method provides a real help to such kind of decision.

What we want to avoid is that the poor (or very poor) quality of the application source code hampers the maintenance activities of the team. In this case the maintenance team will be far from reproducing the expected productivity achieved in other agile projects.

In a SQALE quality model, the first three expected quality characteristics (those shown at the bottom of the SQALE pyramid) are testability, reliability and changeability. An agile team performs cycles where activities of testing, debugging and change keep coming at a high speed. Their velocity depends mainly on their productivity for these 3 activities. The part of the technical debt that corresponds to these activities is thus the main concern. Other parts of debt such as that related to performance or safety will have a very limited impact on the team’s productivity.

In the SQALE method, the debt specific to these three characteristics is called SCCI (SQALE Consolidated Changeability Index). This index represents the « agile debt » of your code. When you divide this value by the size of the code, you get the density of this debt. This index called SCCID (SQALE Consolidated Changeability Index Density) represents the « agility » of your code.

If you look at the two SQALE pyramids below (which show the distribution of technical debt according to its impact on the life cycle activities), it is clear that the two projects have similar amounts of technical debt but very different distributions.

In one case (Application A) the portion of the debt which is relative to the “agility of code” is relatively low; in the other it is rather high. In the second case, it will be probably beneficial to refactor the code before maintaining it in an agile mode.

It takes some calibration effort to know which threshold should be used within a specific organization and a given context, but this dedicated SQALE index is of very obvious interest for such type of decision.

SQALE Pyramid samples issued by Sonar

• 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.

1^st 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

2^nd 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?

« The SQALE Method for evaluation Technical Debt »

Download the accepted paper

When you have estimated the value of your debt, you’ve just made a first step. You know where you are but it does not help you decide where to go and how to get there.

I have tried to describe here what, personally, “Managing Technical Debt” means. This is certainly not a complete inventory, but I expect at least it will contribute to the debate.

In the following lines and as stated by W. Cunningham, I consider Technical Debt as the result of “not right code”.

In my opinion, “Managing Technical Debt” means to be able at least to perform the following:

1) Set project goals related to Technical Debt. Establish quantifiable goals in terms of amount or density, in terms of nature etc. and answer questions such as:

• What creates Technical Debt?
• How is the Technical Debt estimated?
• What is the acceptable Technical Debt (absolute value or density) for the Project?
• What level or type of debt is acceptable (and not acceptable) from the Technical Team perspective?
• What level or type of debt is acceptable (and not acceptable) from a Business perspective?

2) Monitor the amount of Technical Debt over time (either the absolute value or the density) and answer questions such as:

• Has the Technical debt increased during the last day(s)/sprint(s)/version(s)?
• How much margin do we have related to the goal set for the project?

3) Compare the Technical Debt for different projects or subcontractors and answer questions such as:

• Which project/subcontractor delivers the least Technical Debt?
• Regarding Technical Debt density, are we below or over the average other comparable projects?

4) Analyze the temporal origin of the Technical Debt and answer questions such as:

• Which part of the current debt has been created during the last day/sprint/version?
• Which part of the current debt is inherited from legacy code?

5) Analyze the physical origin of the Technical Debt and answer questions such as:

• Which parts (files, packages, components…) of the project/portfolio have the highest Technical debt (in absolute value, or in density)?

6) Analyze the technical origin of the Technical Debt, which means obtaining information on different “bad practices” that generated the debt, (and then perhaps launch awareness, coaching sessions on some specific topics) and answer questions such as:

• How much of the debt is related to architecture issues?
• In this amount, how much comes from cyclic dependencies?
• How much is related to “Exception Handling”?
• How much is related to “copy and paste” instances?
• How much is related to insufficient test coverage?

7) Analyze the points you want to address by reducing the Technical Debt and answer questions such as:

• If I want to preserve/increase the velocity of the project, which part of the debt is concerned and needs to be fixed?
• If I want to preserve/increase the transferability (capacity to be maintained by a third party) of the project, which part of the debt is concerned and needs to be fixed?

8)  Analyze the impact of the Technical Debt from a business perspective (that creates issues or risks for the business)  and answer questions such as:

• Which part of the Technical Debt impacts the security of the application?
• Which part of the Technical Debt impacts the reliability of the application?
• Which part of the Technical Debt impacts the performance of the application?

9) Set priorities for reimbursing the Technical Debt. Be able to optimize the results of a partial payback of the debt (This is the typical situation as it is rare to have sufficient budget to reimburse all of the debt).

• Which are the most urgent issues to fix within my code?
• When I have fixed the most urgent issues and if I have some remaining budget, what are the next issues to fix?
• Which violations of “right code” are not so costly to fix and will generate a high decrease of the impact for business?
• Which parts (files, packages, components…) have the best ratio from a business impact/remediation cost point of view?
• I have exactly 14 hours available. What is the most profitable way (from the business point of view) to spend them?

I had initially identified some additional questions but chosen not to keep them because they are too dependent on context, and need some local feedback and calibration, so they can’t be answered immediately after the deployment of a solution. For example:

If I spend 100 hours to decrease the Technical Debt,

• How much I will improve my velocity?

• What improvement will users perceive on the quality of the application?

I consider that if you have put in place a solution that provides answers to all these questions, then you can really say that you “Manage your Technical Debt”.

I would like to clarify and explain what makes this concept different and powerful.

1. What is important is to stop characterizing non-conformities (or whatever you call them, violations, bad practices…) on a 1 to 5 or 1 to 10 range. This practice, which comes from classic risk analysis methods, is not representative of the issue. In real life, impacts of problems are on an unlimited range. The impact may be 1 for a small problem and 100,000 or more for a “very big”one.
2. If you characterize your non-conformities on a 1 to 5 or 1 to 10 range, you use an ordinal scale. This bans any aggregation by summation. SQALE, through the concept of Non-Remediation Cost, use a ratio scale, which provides a realistic and representative aggregation by summation, as we commonly do for Remediation Cost and Technical Debt.

In many cases, it will be very difficult to estimate the Non-Remediation costs in a tangible unit as hours or $. I recommend using a symbolic unit. The key point is to estimate and represent the real relative impact to the business of the different types of non-conformities.

From now, with the ability to analyze the non-conformities from a Technical and a Business perspective, you almost have the necessary information to optimize and manage your Technical Debt.