As a simple example, your initial website design may need to be frames based because you don’t have time to build an Ajax framework.
I usually use the term to describe the result of developers (more or less conscious) decisions to deliver features that are not really done. When a team is delivering features lacking automated tests, proper refactoring, documentation, or whatever is (or should be) incorporated in their Definition of Done, a debt occurs, because these features though formally delivered still require more work. Perhaps they are hoping that there soon will be more time to go back and actually finish them, something less likely to happen as the code gets messier, or perhaps it is unintentionally by lack of required skills. Either way, the debt is in their code and is collecting interest until dealt with.
If the term Techical Debt is being reserved for decisions to design systems using last year's 1.0 technology instead of a brand new 2.0(RC1) solution, then I need a new name for that other kind of debt. Creative phrases like Deficit Programming or Ignorance Tax comes to mind, but they have a quite elitist and harsh ring to them, and seem less useful as metaphors when discussing causes and consequences of messy code with managers.
Is it time to reclaim (the term) Technical Debt and make it also incorporate messy code, or is there a better name for it? Write your suggestions in the comments!
1 comment:
I think I read somewhere that Ward Cunningham initially used the term in the sense Martin refers to, i.e. making a conscious decision to take on technical debt. Over time, more and more people have come to use the definition you favor. On a side note, I think Jerry Weinberg uses the term in one of his Quality Software Management books from the nineties, but I have to double check that.
Post a Comment