The Nine Transformative Aspects of the Technical Debt Metric
No, the technical debt metric will not improve your tennis game. However, using it could help you generate time for practicing the game due to its nine transformative aspects:
- The technical debt metric enables Continuous Inspection of the code through ultra-rapid feedback to the software process (see Figure 1 below).
- It shifts the emphasis in software development from proficiency in the software process to the output of the process.
- It changes the playing fields from qualitative assessment to quantitative measurement of the quality of the software.
- It is an effective antidote to the relentless function/feature pressure.
- It can be used with any software method, not “just” Agile.
- It is applicable to any amount of code.
- It can be applied at anypoint in time in the software life-cycle.
- These seven characteristics of the technical debt metric enable effective governance of the software process.
- The above characteristics of the technical debt metric enable effective governance of the software product portfolio.
Figure 1: Continuous Inspection
The Agile Executive 
I love it! But I do go back-n-forth on item #1 in that I feel CI *enables* collecting TD metrics. …Or, TD metrics collection *requires* Continuous Inspection.
But that’s splitting hairs.
Items 2-9 however put into words, succinctly, something I’ve been desperately trying to say myself.
Thank you!
Curtis
November 1, 2010 at 11:31 am
Thanks for the kind words, Curtis!
What would be your good counsel how to crisp bullet #1?
Many thanks!
Israel
israelgat
November 1, 2010 at 12:02 pm
If it isn’t obvious already I’m a big fan of the work coming out of the Agile Executive.
I think collecting Technical Debt as a metric is synonymous with Continuous Inspection.
My own view on #2 is that Continuous Inspection levels the field of developer proficiency, acting as a mentoring tool to ensure consistent code quality regardless of experience level and fostering more of a team environment. It also frees up developers from what amounts to grunt work to focus on solving business problems (the output). I think your bullet is consistent with that but maybe it’s not apparent.
1. The technical debt metric *is* Continuous Inspection of the code through ultra-rapid feedback to the software process (see Figure 1 below).
I also see #3 as more of an *augmentation* than a shifting of emphasis. We’re adding the qualitative assessment of the code (TD) to the already existing qualitative assessment of the software (functional testing).
3. It augments qualitative assessment (software testing) with quantitative measurement of the quality of the *code*.
Caper Jones tells us quality is like security, it has to be baked into every step of the SDLC and not just one discreet activity. TD fills a big gap in that regard.
Curtis
November 3, 2010 at 8:12 am