Another metaphor for Technical Debt: Deferred Maintenance

There are a number of blog posts, books, and articles that discuss the idea of “Technical Debt” in a software project. One good (and short) article on the subject is Technical Debt at Martin Fowlers bliki. (He attributes Ward Cunningham with coining the term in 1992, so this is nothing new). I’ve also heard various presentations at conferences and developer group meetings that covered this idea as well, and I find it useful as a way to think about a harmful practice that is prevalent in software development.

Here is my attempt at a description of Technical Debt:

Technical Debt is the accumulation of bad code and design that degrades the quality of a project in such a way that it is harder to maintain, enhance, and support. (That is, the code has become more rigid, fragile, opaque, and so on – which are design smells as presented by Robert Martin in his Agile Principles, Patterns, and Practices books.)

Technical debt is often (but not exclusively) introduced into a project a little at a time so it might not be obvious that it is becomming a problem. After a while, a general uneasiness may be felt, accompanied by resume polishing.

If Technical Debt is not addressed, removed, or “paid down” in a timely manner a compounding effect occurs which leads to even worse problems as people work-around work-arounds, hack hacked code, and further degrade degraded designs. This gives us the analogy to debt on a credit card that is repeatedly not being paid down sufficiently to cover the past month’s interest charge, so that we are paying interest on interest and are going further into debt without spending any more money. Bankruptcy is on the way.

Deferred Maintenance – a slightly different way to look at it

Another way to conceptualize the nature of these harmful practices is as deferred maintenance, which is used in working with real estate or plant equipment. Deferred maintenance is where we put off needed “minor” repairs to save money or because they don’t seem serious enough for us to worry about them. This isn’t a big deal, but if we continue to ignore the little things they can grow into very expensive problems. For example, a small leak in a water pipe on the second floor that isn’t fixed promptly will likely result in rotted out ceilings and floors, crumbling walls, and electrical system problems – and potentially even worse problems. Not every small problem will grow into a bigger problem, but many do. Here is a wikipedia blurb on the subject: Deferred Mainentance at Wikipedia.

So why do we let these things build up? In some ways, it’s like the ancient Arkansas Traveler comedy routine (from the 1850’s):

An old farmer is sitting on the covered porch of his dilapidated farmhouse in the pouring rain playing the fiddle, and he spies an approaching traveler coming down the road.

As the traveler gets near he notices the leaky roof and the water dripping into the house and questions the farmer: “Why don’t you fix your leaky roof?” he asks.

“I can’t, you fool! It’s raining and I’d be sure to slip and fall and break my neck!” answers the farmer, who just goes on fiddling.

“Well, why don’t you fix it on a sunny day?” the traveler inquires.

“Dang, you are such a fool!” responds the farmer. “It doesn’t leak on sunny days!” And on he fiddles in his bliss.

For whatever reason, the farmer is willing to put up with a damp home on rainy days, and isn’t willing to prepare for the next rainy day by fixing his roof on a sunny day. The joke doesn’t go into details about what will eventually happen to the farmer’s home, so you’ll have to imagine that for yourself. But I’d be willing to bet that after just a few seasons the dilapidated farmhouse will fall down into a heap, at which point the farmer will need to move, or rebuild the home.

Of course, this isn’t exactly the way things go in software development, but it hints at the basic thought pattern. You are fortunate if you haven’t worked on projects where the quick but messy solution is often taken in lieu of a more sound approach. The reason given is often some variation of “we need to get this out the door as fast as possible or the customer is gong it sue us” or “this is so minor that we can just hack it in.” These are legitimate reasons in some cases and it is obvious that in many situations we have to take a path that isn’t ideal, but if we don’t get in there and put things right during the next “sunny day” we are headed for some real problems sooner or later – usually sooner than we think. It is unlikely that there is a government program available to bail out our failed project. But then again, what do I know?


Leave a comment