Joel Spolsky recently set off another flurry of discussion in the blogosphere with his post extolling the noble duct tape programmer. Most of it was not too bad. But what could have been a nice rant against architecture astronauts was ruined when he drew a false dichotomy between overwrought architecture and duct tape.
Which brings me to my story.
Just today I came across a charming little piece of duct tape. Here’s how I imagine it got there. During construction of the system some tester reported a problem: “When I do [x] I get an ugly error, and I cannot complete the task.” The job of fixing the error was quickly dispatched to a clever duct tape programmer who “solved” it equally quickly by wrapping about 100 lines of code in a try-catch block that swallows the exception. Before you groan too loudly I should mention that this code has been in production for a year or more. Does that prove that duct tape was the right tool?
Not so fast. Back to what happened today. A colleague and I spent about an hour scratching our heads over a failing acceptance test. It turned out that this little piece of tape was masking a problem elsewhere in the code. What should have taken five minutes to solve took two person hours.
Is it a good trade off? Absolutely! Um well, unless the business needs to change. The thing is, it does need to change. It needs to change a lot. I will venture to say that all businesses need to change all the time. This particular system was built by a team of duct tapers. So our little struggle today is repeated over and over all day every day. The net result is that it takes many times longer than it “should” to maintain and extend the system. Indeed, some extenstions seem out of reach. Conclusion: while duct tape systems may get to v1 faster, they can be very very expensive over the long term in terms of programming labor and worse yet in terms of lost opportunity.