The Technical Debt of Red Green

Recently, I have been seeing a lot of tweets and a couple of blog posts responding to this post by Joel Spolsky on “The Duct Tape Programmer”. In it, Joel implies that agilists just don’t get the importance of having a “get ‘er done” attitude that the so-called “duct tape programmer” has. Apparently, the “Red Green School of Software Development” has much to teach all these ivory tower agilists about how to wield “the handyman’s secret weapon.”

This, of course has met with a fairly poor response in the agile community. A couple of the blogged responses can be seen here from Jeffery Palermo and here from “Uncle” Bob Martin.

Uncle Bob is actually pretty fair with Joel. He agrees that the “spirit” of Joel’s post is right on the money if perhaps the “specifics” are a bit hazy. Uncle Bob’s, post is excellent, however I’m not sure I agree that by ignoring the specifics of Joel’s post make it a “really good post.”

For me, ignoring the specifics of Joel’s post would be a bit like ignoring the specifics of a software implementation as long as it gets the job done, which is exactly what Joel is suggesting we can do.

Joel says, tests can wait, if they are even needed at all, because mostly they just waste time. He suggests that clean code and proper use of patterns and good practices are equivalent to “using complex coding techniques” that will “doom your project”. Finally, he implies that getting the job done despite what to me sounds like lack of understanding of how to use said patterns or the value of unit tests shows great talent… You see, Joel isn’t just suggesting we use a little duct tape, which is what Uncle Bob says (and rightfully so) is ok, he is suggesting we use it liberally if it will get the product out the door.

This, I have a problem with, because for most companies and situations the goal of software development should not be to simply produce a product but to provide a service._ _By this, I mean, the software we design should be able to be constantly improved over time. Each new version should provide increasing value to clients, otherwise, why are they still paying you? I certainly hope they aren’t paying for you to fix all the places where you used duct tape.

Duct Tape solutions, may offer you a “tactical shortcut” but this inevitably incurs the cost of technical debt in the long run. Adam and I have recently been discussing how our backlog works and the need to separate technical debt and bug fixing from features and architecture. As Adam explains, work done dealing with technical debt and bug fixing does not count towards your velocity. This is important because it means it is not productive work. By using duct tape you reduce your future productivity, duct tape programming has diminishing returns the moment you use it. Proper architecture, clean code and test-first design have steady increasing returns.

Being Canadian, I happen to know a thing or two about duct tape and it seems pretty clear, by Joel’s choice of analogy, that he has never seen the Red Green show. Anyone who has, knows that Red has never once built anything that worked with his liberal use of “the handyman’s secret weapon,” duct tape. In general, if you use duct tape instead of careful design to build complex things someone (usually Red) is gonna get hurt.