During my consulting engagements within large organization, I meet senior managers and exchange with them on the topic of technical debt. I would like to share with you:
• The questions that are quite systematically raised by my contacts
• My current answers to their questions.
• My suggestions, my proposal about what needs to be done to make progress?
Is technical debt just a new fad that will pass in a few years?
My Current answer:
No, the concept of technical debt is a true paradigm shift. Once you have adopted this measurement concept, you won’t come back to traditional measurement system for code quality. This is due at least for 2 reasons that are purely mathematical.
The first reason is that technical debt is measured on a ratio scale (principal and interest are unlimited numbers. A file with X0 days of debt has X times more debt than a file with 10 days debt).
Almost all code quality measurement systems that the community has proposed during the last 30 years was producing measures, indexes on limited intervals like [1 to 5], [0 to 10], [0 to 100]. (I remember the MI3 and MI4 maintainability indices). Such measurement systems have representation issues and should be replaced by ratio scale measure. In fact, if we leave the software world and look at the measures we use every day for centuries (weight, distance, area …), they all are ratio scale measures.
The second reason is that technical debt is aggregated with additions. This is the only aggregation rule compatible with a representative measurement system (which means that if the analysis tools are accurate, the system will not make false positives, when aggregating file level measures to build a module or application level measure).
This looks quite short explanations about these two reasons. If you want more details, I invite you to read an article that I published in 2010 and which covers more in detail the measurement theory applied to code measures: Valid-2010 Conference paper downloadable here.
What needs to be done to make progress about the topic raised by this question?
I personally think that this paradigm shift is a huge progress, a major step toward the systematic measure of code quality. I think that the TD expert community does not communicate enough about this major breakthrough achievd by the concept of technical debt.