This is the official site of the SQALE method

What “Managing Technical Debt” means?

By Jean-Louis Letouzey on mar 07th, 2012, no comment

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

Comments are closed.