Summary
I see a lot of agreement in the software community poor quality code and other forms of technical debt slow you down. Where I see disagreement is on how to manage technical debt. What is your approach?

Gregor Hohpe, coauthor of Enterprise Integration Patterns (Addison-Wesley, 2004), asked "Where did all the beautiful code go?" in his keynote at TheServerSide Symposium last week. He made a plea for code quality, as described in a searchwebservices.com article:

As Hohpe sees it, code gets messed up for far more mundane and preventable reasons. Principal among them is that sloppy code begets sloppier code. His theory is that if the initial developer of an application doesn't take care to make his code clear and logical to any programmer that reads it, Pandora's box pops open.

The sequence of events Hohpe outlined begins with the developer writing code that is serviceable for the application – it runs okay – but the code itself is idiosyncratic and hard for another programmer to understand. The along comes a programmer doing maintenance a year after the application goes live. The code appears to be a convoluted mishmash.

So perhaps the second string maintenance programmer working on a revision, says to himself, "I'll just stick my code in here. How much worse can it get?"

After a few revision cycles like that an application that is getting a little long in the tooth may feature code originally developed by the best and the brightest, yet it's going from bad to worse.

Gregor concluded with:

"Write code that people aren't compelled to mess up," he said. "Make code so the next person sees you put thought into an elegant solution."

This reminded me of the Pragmatic Programmer's call to fix broken windows, and show that you care, so others will care, which they discussed on their Artima interview. As Andy Hunt put it:

If you walk into a project that's in shambles—with bugs all over, a build that doesn't quite work—you're not going to have incentive to do your best work. But, if you go onto a project where everything is pristine, do you want to be the first one to make a bug?

The week before last at the Software Developer (SD) West conference, I saw part of a keynote by Uncle Bob Martin, in which he made a similar plea for code quality. His keynote was quite inspiring, and although his main message was that the prime directive of agile development is never be blocked, he touched several times on code quality. He reiterated his belief that, as he posted in this forum discussion a year ago:

The only way to go really fast is to write the best code you can possibly write, with the best design you can possibly give it. Any other technique will slow you down.

His position is that you should always avoid taking on any technical debt. At his SD keynote, Uncle Bob suggested that if you hack something up quickly to get it out the door today, that mediocre code doesn't just slow you down tomorrow, it slows you down today. This contrasts with Luke Hohmann's notion that to minimize risk just before a release, it is fine to take on some technical debt, but that you should clean it up just after the release, a technique he calls post-release entropy reduction.

Frank Sommers and I recently spent two months doing post-release entropy reduction at Artima, primarily by writing some code generators that generated much more consistent correct code than we could do by hand. It was quite expensive, and only made sense to me in the context of where we are planning to go. The more complexity you are planning to take on, the more important I think it is to invest early in building an architecture that will enable you to manage that complexity. But even though in the long term, building architectural pieces like test harnesses, code generators, and proper build scripts, pay off, in the short term they just cost.

I see a lot of agreement in the software community poor quality code slows you down. Where I see disagreement is on how to manage technical debt. What is your approach? When do you take on technical debt? When do you invest time to pay it off?

Talk Back!

Have an opinion? Readers have already posted 97 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Bill Venners adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Bill Venners is president of Artima, Inc., publisher of Artima Developer (www.artima.com). He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Active in the Jini Community since its inception, Bill led the Jini Community's ServiceUI project, whose ServiceUI API became the de facto standard way to associate user interfaces to Jini services. Bill is also the lead developer and designer of ScalaTest, an open source testing tool for Scala and Java developers, and coauthor with Martin Odersky and Lex Spoon of the book, Programming in Scala.