Information Technology Dark Side

Struggles of a Self-Taught Coder

Information Technology Dark Side header image 2

Where Does Technical Debt Come From?

May 12th, 2008 · 3 Comments

Matt Heusser and I were discussing his upcoming Workshop on Technical Debt, at which I hope to be speaking in August, and we came up with several interesting ways that technical debt is created.

Hacks create technical debt by ignoring principles of good software development in favor of quick, easy fixes

This is the obvious one because it is the one technical teams complain most about. “I didn’t want to do it that way, but my manager said I could only choose from options that took less than a day to implement,” or some variant of this statement, is the most common answer to the question “Why does X suck so bad?”

So how do developers typically fight back against hacks? With reuse anticipation. Now the bad news.

Reuse anticipation creates technical debt by expanding the supported code base without creating a correspondingly timely value proposition

It’s easy to imagine that the service, component, module, whatever, that you’re building might be used by multiple applications in multiple ways. It only takes an extra YY hours to make it universal, you tell the project manager. And then we’ll never have to write this code again. Sometimes, when you already have “universal” demand for a component, this is a good idea. It’s also a good idea when it is a very specific, low-level technical capability, like dumping a message in a queue or searching a string for a value or something like that. Sometimes it’s a really bad idea – over-generalizing a capability can make it so difficult to “reuse” that no one will reuse it. Either way, it increases your technical debt, because whether anyone reuses it or not, the code you have to support is more complex than it would otherwise be.

Time creates technical debt
There’s a great riddle in The Hobbit, by JRR Tolkien:

This thing all things devours:
Birds, beasts, trees, flowers;
Gnaws iron, bites steel;
Grinds hard stones to meal;
Slays king, ruins town,
And beats high mountains down.

Tolkien might have included code in this list had he been a software developer.

Time has a way of dimming our memories of the code we’ve written, what it does, and why it does it. It is for this reason that development teams often turn to comprehensive documentation to save them.

Now for more bad news.

Comprehensive documentation creates technical debt
Every document you write that has more purpose than helping you figure out how to deliver code NOW becomes another artifact you have to maintain. It adds to your code base in that regard. Now, instead of paying people to maintain the code, the business has to pay someone to maintain the code and the documentation. You just fell further behind.

Documentation typically only has ROI in the short term. It is a very rare document that provides value over the long term. Usually it very quickly becomes a cost with little return of any kind.

Innovation creates technical debt
Einstein said we can’t solve our problems with the same thinking we used when we created them. Sadly, when we continuously apply the same thinking to our code base that we used when we created it, the technology world doesn’t do the same. It moves on, finding better ways to do the same thing. Small changes add up and become big changes, and suddenly there are much more attractive technologies that we can’t use because we’ve fallen so far behind.

When we see the world moving on to bigger and better ways of solving our problems, it’s tempting to say something like this:
“There’s no point putting effort into X, we’re just going to move to Y soon anyway.”

Sometimes this is a good idea, if moving to Y is funded, approved, and making progress. But if Y isn’t approved, giving up on X will only increase the amount you owe, and you’ll feel doubly bitter about it when Y never materializes.

When I see this problem, I think of a line from an old song: “If you can’t be with the one you love, well then, love the one you’re with.”

Technical debt creates more technical debt
With credit cards it is sometimes possible to make the minimum payment without reducing your principal a penny. In fact, you can pay your bill and end up with a higher balance because of this.

It’s the same way with your code base. If you don’t invest in it faster than you are accruing technical debt, your technical debt will grow. Why? Because you don’t have time to make it better, so what are you doing? You’re hacking – cutting corners and doing the wrong things just to get done in time with the resources you have.

Technical debt sucks as bad as credit card debt. I suspect that paying off technical debt is very similar to paying off credit card debt. It’s hard, it requires frugality, and it means shedding everything that isn’t really important. More about that some other time.

Have a nice week.

If you enjoyed this post, make sure you subscribe to my RSS feed!
Stumble it!

Tags: Architecture · Information Technology Trends · Project Management

3 responses so far ↓

  • 1 bh // May 13, 2008 at 9:06 pm

    This blog could seem a little bit bleak. It seems that everything we do is adding to the onslaught of Technical Debt. It is a truism that today we are building the legacy systems of tomorrow.

    I like the idea of approaching this like real credit cards. Just identify the problems. Then bite off the smallest one first. Then you move on to the next larger one.

  • 2 David Christiansen // May 14, 2008 at 8:54 pm

    Technical debt, like credit card debt, can be oppressive and seemingly unconquerable. So, yes, this post is bleak.

  • 3 kyaw kyaw naing // Sep 14, 2008 at 12:36 pm

    The major cause is lack of self-discipline.
    After that, ignorance ?

Leave a Comment