Questions that are quite systematically raised about TD – (cont.)

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?

Question 2:
What’s the definition of technical debt?

My current answer:
I don’t have a definition of technical debt, because it is a metaphor. You don’t define metaphor, you just use it (if you find it useful).
The metaphor has been introduced by Ward Cunningham, one of the authors of the Agile Manifesto.
Ward used it the first time when he was developing a financial application in Smalltalk. He wanted to justify to his boss the refactoring they were doing, so he used a financial analogy.
If you want to know more about the metaphor, you can:
• Look on the web for some videos, interviews of Ward on the topic.
From what I know, Ward never provided a precise “Definition” of its metaphor. I personally think that it’s a fully deliberate position.
• Look for a recent document on the Agile Alliance web site (here). It is an introduction (not a definition) to the concept which has been reviewed and completed by Ward

What needs to be done to make progress about the topic raised by this question?
I personally think that experts, researchers should stop providing definitions of technical debt. Their posts, their articles provide added value when they share experience, studies, recommendations etc. on the topic. Providing or referencing a definition of technical debt is not fully ethical.
Let me explain my position.
Has a comparison, Tom McCabe introduced Cyclomatic Complexity in 1976. After that, nobody tried to give personal, improved definition of the concept introduced (and so owned) by Tom. The research community focused on studying the concept, finding correlations between the measure and external quality aspects of software etc. Of course, he gets feedback, comments on its concept and its definition. In 1996 Tom published a revised definition of its measure.
The Technical debt metaphor has been “invented” and is “owned” by Ward. If there is one day a definition of the concept it should come from Ward.

There is still plenty of room for work on the concept. The community can bring added value for identifying and defining other complementary concepts like technical debt item, obsolescence, other IT debts etc and for providing methods, practices, recommendations, tools etc for managing technical debt.