On Laziness, Cowboys and Duct Tape

So, Joel has posted something that is causing a bit of discussion (if you don’t need substance and want to kill half an hour, click here).  Though there are many points of interest in his post, I’m guessing that one of the passages that caused the most consternation was this part:

Zawinski didn’t do many unit tests. They “sound great in principle. Given a leisurely development pace, that’s certainly the way to go. But when you’re looking at, ‘We’ve got to go from zero to done in six weeks,’ well, I can’t do that unless I cut something out. And what I’m going to cut out is the stuff that’s not absolutely critical. And unit tests are not critical. If there’s no unit test the customer isn’t going to complain about that.”

In a previous kerfuffle, Joel seemed to be denigrating unit testing in general and TDD in particular, and this naturally got the Craftsmanship Fascists’ panties in a bunch.  A large part of the difficulty is that people are talking past each other.  This is normal, by the way.  Communication is possible, but it is also hard.  Joel seems to equate TDD advocates with architecture astronauts, which is obviously wrong.  The Craftsmanship Fascists (CF from here on out) seem to think that the ‘duct tape programmer’ is just someone who throws some crap code together and slams it into production and hopes for the best, which is also obviously wrong.  Luckily, I’m here to help.

You aren’t a duct tape programmer

Joel explicitly makes the point that the people whom he would call duct tape programmers are few and far between:

One thing you have to be careful about, though, is that duct tape programmers are the software world equivalent of pretty boys... those breathtakingly good-looking young men who can roll out of bed, without shaving, without combing their hair, and without brushing their teeth, and get on the subway in yesterday’s dirty clothes and look beautiful, because that’s who they are. You, my friend, cannot go out in public without combing your hair. It will frighten the children. Because you’re just not that pretty. Duct tape programmers have to have a lot of talent to pull off this shtick.

The average schmuck writing code isn’t one of these.  Part of the issue here, I think, is that the CF group denigrates duct tape.  Duct tape saves lives.  Don’t believe me?  Check here and look at the section on Apollo 13.  Case closed.  Regardless, it is clear that what Joel is talking about is not about randomly slinging shit together and hoping for the best.  It is instead that the end goal is what matters, and it doesn’t matter if there are people who think the processes that lead to a successful end goal think it is pretty or shiny enough.  This is why he says that shipping software is what matters.  He is completely right about this.

Cowboy Programming

During the phase of my career, our company purchased a site that (for whatever reason lost in time) needed to be converted to something that was on our platform.  For various reasons (lost in time), the item on the task list (or whatever it was) sat there for quite a while, until a cowboy programmer decided to rectify the situation.

I’m using the phrase ‘cowboy programmer’ here in the (normally understood as pejorative from an agile perspective) sense of someone who doesn’t follow TDD/XP/Agile/Whatever and just codes what he feels is right to get the job done.  In many, if not most, situations, cowboy programming is looked down upon, and with good reason.

The thing is, this guy was good (Hey Keith!).  He, more or less, locked himself into a conference room over a weekend and ported the site to our platform.  He certainly didn’t do TDD.  He definitely didn’t have detailed requirements.  The requirement was '”port site to our platform.”  And because he was so talented, he did met that requirement.

When you have the talent, being a duct tape cowboy programmer lets you be able to accomplish a lot of things that seem to bypass all of the CF standards that are supposedly so important.  But, the kicker is that you have to have the talent.


One of my high school Physics teachers used to say something like “Intelligent people are inherently lazy.  They don’t want to spend time doing more work than necessary to get a job done.”  I’m pretty sure this was not a vocational message approved by the Administration.

Anyway, I can relate.  When I was doing the whole thing, I was motivated.  Really motivated.  Like many of my co-workers, I had visions of retirement at age 30 from all of those stock options.  Regardless of the visions, I was hot shit.  I could work 80 hours a week, I could be assigned tasks that I’d never ever worked on before and fulfill those tasks as if I was an expert.  We rocked as a team and as individuals.  And I was a perfectionist.  I hated when things didn’t work right.  Our team took over the websites for the NHL at one point, and I remember being angry when the CEO talked about how happy he was about the flawless launch.  It wasn’t flawless.  The individual team sites didn’t work for at least 12 hours (can you imagine!) because of some bugs we didn’t anticipate.  Flawless!  Please.

Fast forward a bit.  I’m still a perfectionist but understand a little bit more about what ‘flawless’ means.  It means providing the expected business value within a reasonable timeframe.  And what counts as ‘reasonable’ and ‘expected’ is defined by the business, regardless of what my perfectionist nature prefers.

More importantly, I’m lazy (or perhaps it is just that I’m tired).  I don’t want to work 80 hours a week, I don’t want to work on oddball tasks, and I don’t want to have to fix things.  So, I write tests because I know well enough by now that if I try to code something without them, I am much more likely to make some mistakes that won’t be found until I run the application, launch the web site, etc.  I want the flexibility to be able to change some code (because the requirements changed two days before production migration) and click a frickin’ button and see green, or (perhaps) better, see red and know I have some things to fix.  Actually, I want to be able to click a button and see gray, but that’s another story.

So, is Joel correct?

The answer is, of course, yes…but.  The ‘yes’ is that software is there to fulfill some requirements.  The nature of those requirements is determined by the nature of the business.  Unless the business requires the shiniest of software as imagined by the CF group, quality is tangential.  Ship what is required.

Then there is the ‘but’.  Things like unit testing are preferable to the typical developer like me because they allow me to fulfill the requirements of the business in the safest, easiest manner.  I know, from personal experience, that the time I don’t spend using SOLID principles, unit testing, etc. will probably be spent, on an order of magnitude higher, in a debugger trying to figure out what went wrong.  I’m experienced enough to know when a certain code path is most likely to cause me pain down the road, and because I know this, I know it is best to create tests around those areas.  Do I need to have 100% code coverage?  Of course not.  Only the CF group thinks that.  But don’t think you can ignore setting up tests where it is required, unless you are a duct tape cowboy.

posted on Friday, September 25, 2009 8:28 PM Print
# re: On Laziness, Cowboys and Duct Tape
Aaron Erickson
9/26/2009 5:41 AM
Man - great essay.

I can relate to a lot of this. I believe maintainability is strongly the right thing - I am seeing it work right now. Man, does it feel good to deliver software that has a score of unit tests behind it, additional functional tests (in our case, selenium) that further still demonstrates things work. It also feels good to have a certain confidence that the design is 'SOLID' - doing the right thing is the default path, which when you are dealing with a team of 20 (my current project), is pretty much the only way forward, regardless of individual talent level.

That said, I can appreciate what Joel is saying. Sometimes, when dealing with CFs, you get the impression that the code is the *most important* thing. It isn't. Delivering stories that create value for the customer is. When you are doing your fourth major refactor of the codebase in 3 weeks to make it "just a little more perfect", you are going off into goldbricking land. Yes, goldbricking - the name for polishing crap more than customer would ever possibly need. CF often risks pushing a mindset that is a bridge too far, that being quality is the only thing that matters. It isn't. It is *one* of the things, and we should measure it, but it isn't the *only* thing.
# re: On Laziness, Cowboys and Duct Tape
Jonathan Neufeld
4/20/2015 2:02 PM
I like to mod Minecraft and it's apparent to me that the Vanilla Minecraft source is the work of somebody in a hurry to get something out the door. The biggest pain points working with the source are violations of the Liskov substitution principle and the open/closed principle. For example it's really not that easy to add a 4th kind of cat because the source doesn't give me a CatProviderFactory object, instead EntityCat has one concrete method that spawns a new tamed randomly selected cat from one of the three variants, and it looks like this:


Now before the CFs go on the hunt looking for someone to crucify, let's recall just how much Microsoft bought Minecraft for...

All the code craftsmanship people make all kinds of well-thought out statements that fail miserably because they do not account for the age-old problem of limited time and resources (space/time constraints).

I rest my case.

Post Comment

Title *
Name *
Comment *  
Please add 1 and 1 and type the answer here: