Schedule and Events

March 26-29, 2012, Software Test Professionals Conference, New Orleans
July, 14-15, 2012 - Test Coach Camp, San Jose, California
July, 16-18, 2012 - Conference for the Association for Software Testing (CAST 2012), San Jose, California
August 2012+ - At Liberty; available. Contact me by email:

Tuesday, October 02, 2007

Technical Debt - II

Before I jump to solutions, I’d like to take a moment and talk about entropy.

(From the site "If you assert that nature tends to take things from order to disorder and give an example or two, then you will get almost universal recognition and assent. It is a part of our common experience. Spend hours cleaning your desk, your basement, your attic, and it seems to spontaneously revert back to disorder and chaos before your eyes. So if you say that entropy is a measure of disorder, and that nature tends toward maximum entropy for any isolated system, then you do have some insight into the ideas of the second law of thermodynamics." -> It's a good read.)

If you think about it, every human accomplishment is a temporary battle against entropy.

Great Buildings are built, last hundreds of years ... and fall.

Cities become kingdoms that become empires, reign thousands of years ... and fall.

Even the great sphinx of Egypt, built in a warm, dry climate with little weather, is feeling the effects of age.

So it is with software. The typical software system might last ten years, fifteen if it is wonderful, but, eventually, the center will not hold. The code will not work on the new operating system, the company will fold, or the company will merge and turn off the legacy system in favor of the new.

In some ways, developing software is a battle against entropy. In some cases, just getting the code into production is a losing battle.

Once the code is in production, the battle starts all over again. Each maintenance change is the opportunity to write a clever hack or make an improvement. In each case, we can trade a little time now for a system that is slightly worse. With each change, the overall impact is un-noticable – but add them up, and we’ve got a mess.

At the same time, no one wants to develop the perfect, new new thing, with beautiful code and perfect documentation – only to be six months late, miss a market window, and have the company go out of business.

The question isn't "to accumulate technical debt, yes or no?", but instead "Just how great can we make this system given our constraints?" (Little things like time and money), "How can we trade off or ignore those constraints in order to have less debt?"

In other words "How much can we invest in this system to save time and money later?"

That is a hard question. I assert that is must be asked and decided consciously. Socrates said the unexamined life is not worth living, and I would add that the unexamined process results in ... crappy products.

We all know the "right thing to do." It's just hard to do it.

So I would like to propose three ways to lead conversations towards less technical debt, focused on –

A) What *you* can do as a technical contributor
B) What you can do as a technical contributor to influence other members of the team
C) Options for management

See you next time ...


James Marcus Bach said...

The debt metaphor is interesting, but it doesn't quite fit. Unlike real debt, technical "debt" gets forgiven on a regular basis. If your product becomes obsolete, the "debt" just goes away.

It's only if you maintain a code-base for the long term that this debt issue becomes critical and chronic.

Shrini Kulkarni said...

I happen to see an article from Jonathan Kohl (he calls it as "Testing Debt ..(a 2005 blog post)

This post also refers another work by Johanna Rothman in this area

Can you see the similarities and differences?


Shrini Kulkarni said...

Software Entropy - what a nice term... I think it deserves a separate post. Great to see your post on technical debt linking Entropy is simply great.

Your veiew of role of "software Entropy" in complexity (growing) of an existing software, new code vs maintenance costs, business pressures (and probably social science issues of people interactions) - is inspiring. Expect more on these lines ...

Interestingly found an article on IBM site - where the author claims to fight Software Entropy with ClearCase - IBM's config mgmt tool.
The paper also touches upon another natural phenamenon - Gravity.

Time to include Entropy in "Creative Chaos" (title) ?

>>What you can do to reduce technical debt?

Understand "entropical forces" in software and just do not rush to make everything great and perfect (do it right first time) etc.

Understand that there are natural forces that are at play to "mess" up every thing that we attempt to do to bring order in Chaos (in Creative Chaos?)



Anonymous said...


This article is good and informative.

Software Development Company

Free Directory

Software Jobs India

Patrick Debois said...


I'm currently working in an operational environment that suffers from a large technical debt.

Technical debt got introduced by several reasons. It is indeed as you say a fact of working within the constraints.

The operational part is more duct tape then anything else. And now it works like a snowball effect: incidents take up more time, less time is left to project work. The operational people only finish the solutions half way. As the project is long gone, they are the only ones left.

It can at the moment not be solved anymore at the technical level. I'm trying to create this awareness to have a separate team for 'operational' projects aside from the operational team who handles the incidents. Projects should take this kind of maintenance team into account when they are calculating the cost of the project maintenance.

It is normal that project tend to focus on the fuctional aspect. But one of the actors they most often forget in their use cases are operations.

Steve Poling said...

I disagree with James Bach that technical debt gets forgiven on a regular basis. What happens is that the new manager and/or programmers look at debt-ridden code and say, "This steaming pile of crap needs to be rewritten." The old code-base is largely tossed away and a whole new set of bugs are brought into existence.

This isn't technical debt forgiveness. It is declaring bankruptcy.