I've been asked to create a report about the technical debt of an application, but I haven't receive further guidelines about its elaboration. I'll be assisted by Sonar code analysis tool.

My main doubt is: What fields would be useful to include in the report? I mean, what metrics, parameters, findings, suggestions, etc. would be the most important in such a report?


When someone asks me to do something and I have questions about what they want, I go back and ask them. That's the most direct way to get an answer.

As a manager, I would want these fields:

  • description, i.e. what's the issue and why it's a problem
  • amount of risk if not fixed
  • pervasiveness
  • level of effort to fix, including testing effort
  • associated bug numbers, if any

Note also that technical debt, as I've heard the term used, is a broader area that the set of problems a code analyzer will identify for you.

| improve this answer | |
  • May I ask you for a little explanation about what you mean by pervasiveness? Is what wikipedia explains in this article? en.wikipedia.org/wiki/Pervasive_Informatics – Eduardo Nov 7 '13 at 19:14
  • I mean how much of the code is impacted by the change, e.g. is the problem in just one place or is it spread all over? – user246 Nov 7 '13 at 20:11

In addition to user246's suggestions, I'd also recommend looking at these areas:

  • presence/absence of unit tests
  • effectiveness of unit tests (that is, do the unit tests cover more than the code paths - they should be covering all the potential logical boundaries as well)
  • presence/absence of higher-level automated tests (including system, API, GUI, integration...)
  • effectiveness and coverage of higher-level automated tests - as with unit tests this is more than simply how much of the code base the higher-level automated tests cover
  • areas of the application where customer-reported bugs cluster - this won't be found by a code analyzer, but it's usually a good pointer to areas of the application that have a high level of technical debt.

I also second user246 about the importance of talking to your manager/lead to find out more about what they want to see in the report. You've got a very broad task here: your manager could want a detailed analysis, or they could be looking for a thumbnail guide to where they need to focus improvement efforts.

Regardless, I strongly suggest talking to the developers and testers - anyone who has worked with the application for any length of time will have a good idea where the problem areas are. In my experience, the problem areas in an application are the areas with the greatest technical debt.

| improve this answer | |

SonarQube is one step in identifying common tech-debt, like code-smells or code-complexity, duplicate-code and lack of test-coverage.

The second step is like Kate Paulk suggested to talk the developers as they know where they took shortcuts, build quick-hacks or what the unmaintainable parts of the code are.

Log tech-debt and make it transparant:

Our team has a list of tech-debts on our wall. It contains code clean-up todo's. Going from removing sleeps from test-code, upgrading libraries, but also refactoring a class because it hard to understand. If you team does not record tech-debts I would suggest to start to create awareness as well. SonarQube alone is not enough.

The business should have a fair view on what technical issues need to be resolved in the future. Releasing features quick to make a milestone (pitch, demo, contract) is good if your business depends on it, but always take note of how this will effect in the long run. You will go slower and slower if your team goes from hack to hack to get shit done too quickly.

If you're an Agile team add the tech-debt to the backlog to make it visible and transparent. Just like with defects I would advice a zero-tech-debt policy.


| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.