It’s Not About The Duct Tape It’s About The People (And More)

I’ve had a lot of fun the last few days following the controversy cause by Joel Spolsky’s post, The Duct Tape Programmer. I actually wish the software development part of the blogospehere would produce more posts like it, because it induced such a tremendous response (both positive and negative). Ultimately we all benefit when everyone chimes in and shares their opinion on an issue (we all get to learn from each other). Of course now that I have said that, it would be remiss of me not to add my own 2 cents into the mix :). The way I see it, Joel stresses 3 distinct points in his post.

Good Programmers Ship Product

ShipSome believe that because Joel has a successful track record of shipping software he must be right (with some caveats). I have to say that I completely agree with this one, shipping is key. No matter where you work as a developer, your job is ultimately to deliver value, to the business, to the customers – whatever. Software that has not shipped can’t deliver any value and is by that definition useless. So far so good. The place where I began to have an issue was the clear connotation that ‘duct tape programmers’ ship software while everyone else is just holding them back. To be blunt that is crap. You don’t have to be a Joel-style ‘duct tape programmer’ to be delivery focused. Anyone who has ever worked on an agile team can tell you that.

Agile teams do not fit the ‘duct tape programmer’ definition that Joel puts forward. They try to use the right tool for the right job and over-engineering is a no-no (this does fit the mold), but agile teams are also very focused on quality. That means having processes in place that will assure such quality, unit testing, continuous integration etc. Whether such quality processes slow you down can be debated ad nauseam, what can not be debated is the fact that the quality does not come at the expense of delivery focus. The business is fully aware of the fact that such quality measures are in place and are willing to live with it because they ‘listen to the experts’ and trust their team to have the best interests of the business at heart. But, if push were to come to shove and quality needed to be sacrificed to meet a deadline, a good agile team would do it, they wouldn’t like it, and they would make the business aware of the price they would have to pay, but they would do it.

This I believe, is ‘duct tape’ mentality without going cowboy style. The point I am trying to make is that just like there is more than one way to skin a cat, there is more than one type of ‘duct tape’ programmer. If you’re currently working on an agile team, then congratulations, you could already be a duct tape programmer, maybe not the same kind as Joel likes but as far as I am concerned, if it walks like a duck and quacks like a duck … well you get the picture.

Unit Test Have No Value If They Get In The Way Of Shipping Product

InTheWaySome people seem a little concerned at Joel’s cavalier attitude to unit tests. Read the post closely, he is not really having a go at unit testing (well he is to some extent), what we’re really talking about is the quality of the talent we work with. Case in point – the ‘friggard’ who writes multi-threaded COM apartments (whatever the hell that is – I doesn’t buildz them Winderz codez :)). The guy is obviously freaking smart, head in the clouds, but smart. The ‘duct tape’ programmer is just as smart, more down to earth but still a bona-fide savant. Wouldn’t it be great if we could all work with superstars all the time? Problem is, software development is a big industry these days, not everyone can be a genius, a great many are either not experienced enough or simply not talented enough to understand the ‘friggard’, but by that same virtue they can’t really be a duct tape programmers, they wouldn’t know which brand of duct tape to use.

What I am trying to say is this, really good people (developers) will create great software, ship it and make it reasonably high quality no matter what the process, no matter how much unit testing. Of course the scale and the type of software matters, web apps or desktop apps are pretty well-understood, but even star people will struggle to deliver decent quality when building something highly complex and cutting edge. However in your regular day to day work, put a bunch of awesome people together, give them an objective, unleash them on it and watch them go, it will be awesome.

Unfortunately most of us don’t work for Fog Creek or Stack Overflow or whatever, millions of developers work for bank ABC or insurance company XYZ where you can’t really rely on the fact that all other developers will quite be at your level of duct tape awesomeness :). And this is where stuff like unit tests saves everyone’s ass, mine yours and the company’s because when you know your team is not Macgyver enough to patch a go cart on the fly, it kinda helps to make sure your go cart is unlikely to need patching in the first place. I don’t necessarily agree with Uncle Bob, there are cases when unit tests can slow us down, but we pay that price for peace of mind.

What if you are lucky enough to work for Melzer and Smelzer accounting with a group of awesome people? Does that mean we can all just go guerrilla with our duct tape and achieve new heights of shipping awesomeness? Problem is, there is that pesky future to think of. You’re not lucky enough to own Melzer and Smelter (unless your name is Melzer, errr or Smelzer I guess, but then you’re probably an accountant) you’re not always going to be working there, people are gonna come after you leave and they will have to use your code, modify it, enhance it and ship it some more. Not all these guys are gonna be duct tape genius material and even if they are, it’s just common courtesy to not leave a dogs breakfast in there hands. Think of it as paying it forward (I’ve said this before and will say it again), cause when you come to a new place, no matter how great your software development kung-fu is, if the software you have to work with is a bunch kitten barf you’re not going to enjoy the stink.

Go Get The Book?

There is no doubt that Joel writes a damn good blog post, I’ve got a lot of respect for him and for what he has done in this industry. Joel is also a clever marketer, the post he wrote was controversial enough that the well-blended promotion of Coders At Work was pretty much seamless (and no doubt he was aware that would happen). Now, I have no idea if Joel is in any way affiliated with the book, or if he simply promoted it because he liked it so much (it does seem to be somewhat similar in format to the books he himself released), what I do know is that he certainly made me want to go and check out the book. As someone who studies online and offline marketing as a hobby, I have to give him major kudos for that one.

Well, there you go, that’s my thinking regarding this whole kettle of fish, hopefully it was at least somewhat coherent :). If you have some thoughts about my thinking, do share them with everyone – in the comments.

For more tips and opinions on software development, process and people subscribe to today.

Images by Flowery *L*u*z*a* and Jonas B

  • “there are cases when unit tests can slow us down, but we pay that price for peace of mind.” Thank you! It’s like you read my mind. I work in a group with very smart people, but when our integration phase hits and everyone is scrambling around to get their code shipped tons of mistakes are made. Several of these stupid rush-mode mistakes could have been avoided with simple unit testing. Taking the time to write unit tests may hurt your development budget a little, but they can end up saving you tons of time and money later on down the line.

    • Depending on what you do, unit tests can make you work even faster so you’re actually helping the budget. For example, when you technologies and/or domain is well understood and the people know what they need to do. In this case unit tests take no time and save stupid errors.

      When the work you’re doing is mainly exploratory or the domain is new, unit testing and especially TDD can be oh so painful, still useful but there is no doubt that it will make your work go slower. I’ll probably write post about it at some point :).

  • Good article. Seems like the backlash to the latest Joel diatribe of writing unmaintainable code is “there is a middle ground.” I certainly agree.

    As for the book… I avoided it because of Joel. There’s a anti-marketing filter hard wired in my head that tries its best.

    • Everything in moderation and finding the middle ground with everything you do is my current mantra not just with work but with life. There are no universal absolutes (well there are, but you know what I am getting at :)).

      I don’t so much mind the marketing I find it fascinating. Although blatant affiliate links do get under my skin a little bit :). The least people can do is go to the effort of cloaking them :). Seriously though there is nothing wrong with making money from promoting products, if you can do it then by all means go ahead and do it, as long as you don’t misrepresent the fact that you’re promoting a product to make money off it.

  • Mike

    Yeah I got to agree with you there, there are no absolutes there’s always a balance of both sides. You don’t want to over-do unit tests, (to the point that changing any part of code needs a massive unittest updates, or there are so many tests they take hours to run) but nor do you want no unit-tests, where if you make a seemingly small change you have no idea if you’ve broken some critical part of the system.

    • Hey Mike, that sounds like an eminently sensible approach to software dev in general and unit tests in particular :).

  • Bob Foster

    …if it looks like a duct and quacks like a duct… ;)

    • Hehe, yeah that’s kind of the analogy I was going for :)

  • Thanks for taking the time to explain the approach to software dev. I’ve been thinking about similar topics lately, and it’s good to see that I’m not alone. What do you think about decadant programming languages?

    • Not sure what you mean, could you be more specific?

  • Dathan N.

    If by duct-tape you mean going Macgyver, it might get the job done fast but it’s not necessarily the most elegant, extensible, or maintainable solution. It should be frowned upon except in wost-case or emergency scenarios. I’d prefer the “best practices” developer on my team.

    • That’s exactly right, sometimes it is necessary to do something Macgyver style i.e. hack a solution together out of nothing, or patch something with matchsticks and beer cans, but it is usually an emergency measure where doing nothing would be much worse. You want people who are committed to creating quality software in sustainable ways (of course if they are capable of stepping up Macgyver style when necessary, that’s just an extra bonus).

  • Cody Burleson

    You know… what I really like is the fact that someone writes something with spirit and soul. In our world of dry and relentless “30 cool new ” posts, reading something spirited and human is just delightful to me – even if I do not agree with the opinion. I have enjoyed both Joel’s and your own commentary. It just reminds me that behind all of these bits and bytes are just people – real human beings – with opinions, world-views, personal experiences, etc.

    And this is what we do.

    We – human software developers – write software for – humans.

    And its the most splendid job full of the most extraordinarily interesting people.

    You guys make me proud to be involved. Keep thinking out loud!

    • Man, I completely get where you’re coming from and I am right there with you :).

  • Pingback: All About the Duct-Tape Programmer | Thought Clusters()

  • It should be frowned upon except in wost-case or emergency scenarios. I’d prefer the “best practices” developer on my team.

  • Jonathan Neufeld

    There are always deadlines and there are always limited resources, this is simply how the cosmos works. A good developer holds to the following:

    * Perfection is a myth

    * Time constraints are constant

    * All abstractions fail to abstract

    * All messes will eventually have to be cleaned-up

    * Every line of code eventually gets thrown away

    * Versatile code and shiny code are not the same thing