Mar 15

What Managing Technical Debt means

Being able to estimate the Technical Debt of an application is a good point. With historical data, it allows to monitor the debt and detect progress or regression.

But developers need more, they expect to manage their technical debt. That means to be able to understand and analyze the debt. They need to be able to assess the level of risk associated to their technical debt. They need guidance for setting priorities for reducing this debt. They want to optimize their resources and expect to get the best ROI of their improvement activities.

Managers on their side want to manage the technical debt at portfolio level. They expect to be able to estimate, analyze and understand the technical debt of their complete portfolio. They would like guidance for identifying highest risks and allocates refactoring, improvement budget.

There is some consensus on the definition of Technical Debt, but to our knowledge, there is no accepted definition of what “Managing Technical Debt ”  means. In my opinion, that means, at minimum, to be able to answer questions like :

  • Has the technical debt increased during the last day(s)/sprint(s)/version(s)?
  • Which parts (files, packages, components…) of the project/portfolio have the highest technical debt (in absolute value, or in density)?
  • How much of the debt is related to architecture issues, lack of comments, lack of unit test, duplicated code…..?
  • Which part of the technical debt impacts the reliability, the security, the maintainability….. of the application?
  • I have about 10 hours (or 10 days, 10 weeks..)  available. What is the most profitable way to spend them?
  • Which application(s) of my portfolio need the highest attention. Where to focus resource for repaying some part of the technical debt.

If you can answer to all of these questions, then, you control and “Manage your Technical Debt”.