Joel, in his inimitable way, posted the flame bait of all flame bait posts yesterday, explaining the role of the Duct Tape Programmer.
To my surprise, the Twitterverse started to reverberate with commentary, but weirdly, almost all of it was very negative about the post, many claiming that Joel was just creating straw men and knocking them down, or was characterising developers who care about quality as being poor developers.
I was surprised, because I read the article totally the other way around - and had said so earlier in the day to someone on Twitter, saying I largely agreed with it. It seems that there were two ways of reading the article, and mine differed substantially to most people I follow on Twitter.
I was quite pleased to see Michael Neel post last night in a semi-defence of Joel's standpoint, and I thought the 140 char limit of Twitter wasn't enough for me to post my opinions.
Joel has a bit of a record on this, he isn't best liked by a large proportion of the developer community who see their focus and remit as producing high quality, well tested and highly maintainable software. His original tirades in a podcast about his deep distrust of Test Driven Development and of Unit Testing in general brought uproar. And on that matter he was so far off the mark, it was understandable why he had riled so many people - he really just didn't understand or "get" TDD or testing in general.
But, what he had done, in conjunction with Jeff Atwood, was to deliver a website, stackoverflow.com, that was proving hugely successful, and was being used extensively by all those same developers who railed against his podcasts and blogs.
That website, as Joel and Jeff explained, was not done with TDD, was not well tested (via Unit Tests), was badly hacked together in places, and used "old" technologies like TSQL over "modern" solutions like ORMs
Whether Joel "got" TDD wasn't important, what he and Jeff had done was to ship a product, get it to market, and build upon that release to make stackoverflow the massive success it is today. It's so successful, that soon after stackoverflow was released, they used the same code and model to release other Q&A sites, and they continue to do so.
The Duct Tape Programmer
So with all of that in mind, it was sort of obviously flame bait for Joel to make a post that basically boiled down to "shipping it way more important than fancy patterns and great tools" - he certainly has a way of putting such a simple message that can antagonise the meekest of individuals (and some not so meek).
It was a terrible choice of label, but I guess "Pragmatic Programmer" had already been taken.
Time, Quality, Functionality
I read the article slight differently - I read it as an urge to maintain your highest priority as shipping the product your business wants you to ship.
There are three factors involved in a project (if you exclude Resourcing, which falls under Brooks Law):
- Functionality (or Scope)
If you try and maintain all three factors as fixed, your project is doomed to fail. Something will, unless you are really lucky, break. And then one of those factors will suffer, and it will be luck as to which it is. At best you can fix two of those factors, and then the third has to be allowed to slip when the unexpected happens (as it always does).
But, the important part here, is that which of those factors is fixed, and which is allowed to slip is NOT a developer decision - it is a business decision.
Much of the outrage about Joel's article stated that he isn't a developer - and they are correct - he is a business owner, and prior to that a project manager. His focus is therefore on shipping his product, and inevitably from that perspective, the instinct is to fix Time and Functionality (ship as soon as possible, with as much functionality as possible) and to let Quality suffer to achieve that objective.
This is a TOTALLY VALID business decision - it is just one that developers don't like, it offends their sense of code quality and high standards.
Why Do Developers Care So Much About Quality?
I'll start with the cynical view: development is only fun while you are trying new things, trying to perfect a tricky algorithm, or make some great new OSS component do some magic. By nature, the developers who care deeply about quality are also perfectionists, they like to make sure they have done a good job, and have written the best code they can.
Go on, admit it, if developers just did routine coding all day long, our jobs would be boring. We like new toys, new language features, we like to play.
And we know that better code will be easier to maintain - and developers HATE bug fixing duty, so we want to ensure we don't have to do much of it.
To a developer, the most important factor in any project is Quality, followed by Time (because we know our bosses will be mad if we miss our deadlines), but we are happy to slip Functionality because it matters little to us if a new feature isn't included in the release.
Fundamentally We Are Not Aligned
Developers and business owners are not aligned in their goals - we prioritise the three factors very differently, and for different reasons.
Only two things can happen here, your developers need to align with their business objectives, or the business needs to align with the developers - or they can both compromise.
Agile is all about the compromise, making both sides aware of the issues involved, and then coming to an agreement, but fundamentally - it is STILL A BUSINESS DECISION.
While it is the responsibility of a professional developer to explain all the problems they see with low quality code, and to make their boss aware of all the potential future issues this may cause, it is also their professional responsibility to go with the decision their boss makes.
They have one other option - resign and go somewhere that is more closely aligned with their values.
Ship It or Ship Out
Whatever your opinions of Joel and Jeff's understandings of TDD, Unit testing, maintainable code or just code in general (and I'm sure yours aren't too far from mine), you have to admit they delivered a product to market (many in fact), and have turned it into a huge success. They may have to pay for that speed to market later, but that was a business decision they were willing to take.
Never underestimate the value to a business of being fast to market - there is a risk the product will be so bugged it will backfire - but there is a chance they could steal the march on their competitors, and gain critical traction. Business is all about assessing risk, that is what a business owner has to do, and if they do it right their business flourishes.
If your boss wants a product shipped by a particular date, and that is their highest priority, you have a responsibility to ship it. If they won't sacrifice functionality to achieve that goal, then code quality will have to suffer - in that case do the best you can do with the restraints you are under. And if all that fails, quit, go somewhere that appreciates your values and dedication to your art - you do not have a right to hold your employer to ransom.
So, Ship It or Ship Out.
09-25-2009 9:38 AM