Technical debt is a concept introduced in IT systems to tackle a very simple problem. Over time, quality of IT systems decrease because of the short-term tactics. (some discussions in infoq)
Short-term tactics causes business decision which forces IT organization to build systems or adopt them in a way which is not wanted by IT organization. As a result IT systems are not ideal, they’re not in the quality IT organization would like. Common symptoms are difficulty of maintenance, low flexibility, low extensibility etc.
It’s not only IT organization who suffers from the short-term tactics. Business also suffers. They are left with IT systems which are difficult to adopt. They’re blocked them to implement new products or processes. This is very dangerous, even self-destructive.
Well, solution is easy, according to some. Let’s measure the technical debt, so that we’re not blocking short-term tactics, and in the same time making sure decrease in the IT systems are transparent to business and they have to pay for it.
There’s a very fundamental trust problem here. IT doesn’t trust business to make decision which will not recover the damage made by the short-term tactics. Business proves their inability to stick with short-term goals. That’s one side. Business doesn’t trust IT to deliver systems which can help them to achieve long-term strategies without compromising short-term goals. Whoever is trying to solve this trust problem by introducing a ‘technical debt’ concept is making a big mistake. The fundamental problem is the problem of trust here, not quality of IT systems. Trying to increase the quality of IT systems without solving the trust problem is doomed to fail.
For those who are now interested in measuring technical debt, I recommend to work on the trust issue. VPEC-T framework is a good candidate to start tackling such a problem.