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
Some 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
Some 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 skorks.com today.
Images by Flowery *L*u*za and Jonas B