InfoQ has a great article about technical debt. Most of all, I like one of the definition of Uncle Bob,
A mess is not a technical debt. A mess is just a mess. Technical debt decisions are made based on real project constraints. They are risky, but they can be beneficial. The decision to make a mess is never rational, is always based on laziness and unprofessionalism, and has no chance of paying of in the future. A mess is always a loss.
I have always known that some technical debts are unavoidable, but had a hard time deciding who should be the person that dictates what should be technical debt. The answer, the team. The team should be the one that decides (as long as we can provide all the parameters and waive all the risks and benefits) what should be included in the technical debt. I agreed with Martin Fowler,
The key lies in making sure that a team is not introducing reckless debts which contribute to the mess and are very difficult, if not impossible to deal with.
