Home > Enterprise Architecture, VPEC-T > Technical Debt

Technical Debt

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.

  1. December 7, 2010 at 18:17

    I strongly agree with you here: accumulated technical-debt is often an outcome of lack of trust, and attempting to use concepts of technical-debt without addressing the trust-issues will only make the problems worse. Also agree that VPEC-T is a very useful place to start addressing the trust-issues.

  2. December 10, 2010 at 15:58

    It’s not trust, it’s trustworthiness. I’d be foolish, for example, to trust a wild animal not to bite me.

    “IT doesn’t trust business to make decision which will not recover the damage made by the short-term tactics.” Correct! However, that lack of trust is well justified.

    “Business doesn’t trust IT to deliver systems which can help them to achieve long-term strategies without compromising short-term goals.” Also correct! Without visibility in the schedule to repair the things that need to be fixed, bad engineers will compromise quality. Good engineers will fix them on the sly, jeopardizing short term deadlines.

    Technical debt is real. Products –and more importantly, the work environments in which they are developed– suffer when the business side appears unreceptive to the developers’ needs. I’m sure I’ve not heard anyone suggest that surfacing technical debt makes for an “easy” solution. But keeping two sets of books is hardly in anyone’s best interest.

  3. December 12, 2010 at 23:03

    @Morgan, technical debt is real, no doubt. Measuring it and implementing processing which deal with it is far from “easy”. I claim, without addressing the cause, trying to deal with it cannot be successful. Therefore organizations must address the trust issues.

    • December 12, 2010 at 23:48

      @Iyigun, Thanks for your thoughtful words. I think that we do not really disagree too much, but perhaps I don’t have a correct definition or understanding of the word “trust” in this context. This is why I used the term “trustworthiness.” If developers began to hit deadlines with consistency, and if the product owners began to value efforts that supported maintainability/quality, then each would be demonstrating that they are worthy of the other’s trust.

      Maybe where we do disagree a bit is that I think that technical debt is more valuable to make those changes happen than you do.

  4. December 20, 2010 at 20:31

    I think you hit on a critical point w/respect to communications. We are IT professionals but must speak in terms every business person can understand. If we want our business partners to allocate the resources to address technical debt we don’t ask them to do it based on “trust”.

    We need to provide them an ROI that they can use to compare to other priorities and make an informed decision. I provide an example of this in the remediation section of a series of articles I wrote on the subject. The folks writing the checks need to be able to understand the value of their investment!


  1. December 19, 2010 at 06:33
  2. April 3, 2011 at 12:44

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s