Archives par étiquette : Techdebt

The benefits of the Technical Debt concept

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?

What “Managing Technical Debt” means?

Estimating the value of the Technical Debt of a project is not enough to be able to manage it.

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

Technical Debt and Business perspective

A new concept: Non-Remediation Cost

The current version of the SQALE Method Definition Document supports and helps to manage the Technical Debt of an application/project. The new version of the method (which will be publicly released soon) will continue to use the debt metaphor and help you to manage two concepts:
•    The Technical Debt, which is now well understood. (If needed, you will find more detail here. If you want to know everything, there is the complete reference book from Chris Sterling here). I remind you that the SQALE Quality Index is an objective and precise estimation of the Technical Debt accumulated within a piece of source code.
•    The Non-Remediation Cost, a new concept, which I want to introduce here.

I will introduce the Non-Remediation Cost concept with a simple analogy.
Let’s imagine that you need a new office building. So, you write a specifications document, which contains your functional requirements and also your quality requirements. Here are two examples of such quality related requirements:
•    For security reasons, you require video cameras at strategic locations of each floor
•    For thermal insulation reasons (or whatever reason), you require that all windows have double glazing.

If during the building phase, you or the building team discovers some non-conformity regarding these requirements, the building company will evaluate the remediation cost of the issues in order to understand their relative importance and their impact on the project’s planning and budget. The useful information during all the building phase and the concept which will be used by the development team is the “Technical Debt”. The Technical Debt is a relevant measure to manage non-conformities during the building phase.

Let’s suppose that very close to the delivery date, you visit the building for control and you discover 5 single glazing windows and 2 missing video cameras. As there is not enough time to fix the 7 issues, you will be obliged to find a compromise. Which information will help you to make the smartest decision, the best compromise?
In fact, you will look after the cost of leaving the non-conformities and you will try to answer the following question:
What will be the impact of leaving simple glass window against missing cameras in some places of the building?
At that moment, what counts is the business perspective. That means the real or potential damages resulting of the non-conformities. The monetization of the damages can be summarized as a cost which is transferred to the client and/or the owner, that’s what is called the “Non-remediation Cost” (you also may call it the “Business Debt”). The Non-Remediation Cost of each issue will be compared to its Technical Debt in order to set remediation priorities.

To summarize the metaphor:
The cost of fixing a non-conforming window is a Technical Debt, that’s the cost that the building team will have to pay to fulfill its commitment.
The extra heating cost (and the total monetization of all other damages) resulting of keeping a non-conforming window is a “Non-Remediation Cost” transferred to the owner – the business, and resulting of the delivery of a non-conformity.

Non-Remediation Cost applied to source code quality

Now, if we apply both concepts to source code:
First I remind you that within SQALE, source code quality is simply compliance to source code related requirements.
The Technical Debt represents the cumulated negative impact of the non-conformities on the real development cost of the project. The interest of that debt is a decrease of development productivity.
Technical Debt will impact the figures of the Development Plan.

The Non-Remediation Cost represents the cumulated negative impact of the same non-conformities on the real business value of the project. The interest of that debt is a decrease of the project’s ROI. Non-Remediation Cost will impact the figures of the Business Plan.

Both concepts and the metaphor apply to all types of development methods (agile or not). Both concepts are the monetization of stated non-conformities.
The Technical Debt represents the technical perspective of the findings; the Non-Remediation Cost (or Business Debt) represents the business perspective of the same findings.

How to use both perspectives

When you just want to monitor source code quality, you just want to monitor “how far” you are from your quality requirements. Then you will mainly monitor and analyze your Technical Debt.
If you want to optimize your quality versus your effort, then you will use both concepts, both information, the Remediation Cost and the Non-Remediation Cost. You will spend your limited remediation budget on remediations with the best ROI. That means, you will try to decrease your transferred costs (Non-Remediation Cost) while spending the less remediation effort.

The following graph illustrates the usage of both concepts.

I think the new concept just provides the means to manage the remediation’s priority as you manage the feature’s priority:
Priorities regarding the implementation of functionalities are established by taking into account associated development costs and business values.
In analogy, the remediation’s priority of non-conformities is established by taking into account associated Technical Debt and Non-Remediation Cost. The analogy is illustrated below:

In conclusion, the two concepts provide two different perspectives, two different pieces of information for analyzing and managing the non-conformities of your code. The Technical Debt is a first level indicator for day to day monitoring. The Non-Remediation Cost is a second level indicator for performing optimization, compromise and setting priorities.
The new version of the SQALE Method Definition Document (coming next month)  will support you with relevant indices and indicators.