Duct tape, reloaded

In a recent article, Joel Spolsky discusses the concept of the “duct tape programmer”. According to Joel, a duct tape programmer is a developer that “gets things done”. They don’t spend too much time over designing, discussing or writing tests: they just sit down at their desk and code until the feature is ready to be used by customers.

Joel uses Jamie Zawinski (jwz) as the perfect example of a duct tape programmer. For people who don’t know jwz, he was made famous during the Lucid/XEmacs/Netscape era. He was known for never sleeping and tirelessly being busy coding. His contributions include vast portions of XEmacs (in C and Lisp) and countless features in Netscape. He retired from coding a few years back, bought a club in San Francisco which he uses to organize events. His web site still shows his undying geekdom and if you’ve never had a chance to read about them, check out some of the pranks he came up with during his tenure at Netscape.

jwz is the perfect example of a duct tape programmer and the kind of developer that Joel would want on his team, as opposed to “software astronauts” that spend more time discussing problems than implementing solutions.

Clean Code is code that hasn’t been run enough times

Not surprisingly, Rob Martin didn’t like Joel’s article. Although he tries to be civil and compromising, Rob is pretty much at the other end of the spectrum when it comes to software development. In particular, Joel’s emphasis that testing should come second since it doesn’t directly impact customer satisfaction rings a sour note with the entire Agile community.

The funniest part in Rob’s rebuttal article was:

Programmers who say they don’t have time to write tests are living in
the stone age. They might as well be saying that man wasn’t meant to
fly.

Well, man is indeed incapable of flying, which is why we need to use devices to achieve that goal.

Joking aside, Rob’s assertion that a software product that is not tested is necessarily buggy is pure fantasy. There are thousands of software products that we use regularly that are probably very poorly tested (or poorly automatically tested), and yet, they work and they are fairly usable.

The crux of the disagreement can probably be found in Rob’s following statement:

I want you to ship, but I don’t want you to ship shit.

Nobody can disagree with this, but I bet you that Joel and Rob have very different ways of defining “shit” in the software world. For Joel Spolsky and Jamie Zawinski, “shit” is a product that is buggy or unusable. For Rob Martin, “shit” is software that wasn’t designed with TDD and that doesn’t have 100% test coverage.

In order to understand their standpoint, it’s important to keep in mind who these two people are and what they do. Joel is the founder of a fairly successful software company and their flagship product, Fogbugz, a bug tracker, seems to be quite liked by its users. Rob Martin is employed by Object Mentor, a methodology consultant company.

They both have something to sell, although it seems to me that Joel probably doesn’t expect that this kind of article will help boost the sales of Fogbugz. On the other hand, it’s important for Object Mentor to make sure that Agile, XP and the other methodologies that their business is based on, keep being discussed and cited as positive technologies that help deliver products faster.

Is Agile on the way out?

Joel’s article is just the most recent example of a growing backlash that is slowly building against Agile and XP. Here is another testimony from Mike Brunt, someone who has had a terrible experience with the practice.

Even though it’s unlikely that Joel and Mike know each other or read each other’s article before writing their own, some of Mike’s points are very close to what Joel is saying. For example:

Agile programming emphasizes coding.

This may sound like a good thing but it really is not, especially when you emphasize coding over feature #1 (shipping). Unit tests fall into that category. Unit tests are tools for the programmers. They are a convenience, one of the many ingredients that you use in the kitchen but that your customers really don’t care much about.

The extreme emphasis on developer comfort (unit tests, code coverage, TDD, etc…) over the satisfaction of your customers is something that has always deeply disturbed me in the Agile/XP movement. I have expanded in more details on this topic in my book, so I won’t repeat everything here, but there is another point that I feel strongly about: if I have time to write either a unit test or a functional test, I will always pick the latter, because such a test will exercise a feature of the product that my users will be seeing, as opposed to a unit test, which is only destined to make my life easier (i.e. find bugs faster).

Agile is fragile

The comments on Mike’s articles were not very friendly. It doesn’t take much to get Agilists riled up, and this post was no exception. However, most of these comments are all using the same old tired argument: “if you use Agile and it didn’t work for you, you were not doing Agile properly”.

This argument is very similar to the one you read whenever somebody dares to post that Linux is not working out for them: “Oh you’re using Fedora (1)? No wonder you’re having these problems, you should be using Ubuntu (2)”. Replace (1) and (2) with any of the Linux distributions and you basically have the template of the response you will see on any post that dares to criticize Linux.

This sort of answer is very similar to “Oh Agile didn’t work for you because you were doing Agile wrong”, and both these statements come from delusional people who just don’t understand that if their technology is so hard to use “right”, then it’s useless.

Brittleness in software

Linux and Agile/XP are both technologies that I call “brittle”. Brittle because you need to manipulate them very carefully or they will just explode in your hands. Brittle because you need to follow extremely precise guidelines to use them, and failure to do so dooms you to failure.

Finally, they are brittle because the amount of expertise necessary to use these technologies is simply too high.

However, Agile/XP is in much worse shape than Linux, which has quite a few success stories. Put in the right hands and used in the right conditions, Linux can do wonders, and hundreds of companies (including my employer) can attest to that. But Agile/XP doesn’t really have any track record of success to show despite many, many years of trying to become mainstream.

Ironically, the few times where I have seen a few Agile practices being successful was when the teams using them were cherry-picking from the Agile manifesto. They read all the points in the Agile manifesto, chose the practices that made sense to them and disregarded the rest. And it worked.

Agilists are not very agile

There are two paradoxes here:

  • Teams that “don’t do Agile” (i.e. they don’t follow the manifesto to the letter) can be successful.
  • The very same people who advocate Agile are actually far from being agile and open-minded. “Agile means this and no variation is allowed” never sounded very agile to me.

I know Rob Martin really believes in all these principles he advocates, but it’s really hard for me to forget the fact that he’s making a living out of them. If software methodologies become easy to apply and they no longer require a five day course to learn, his employer will go out of business.

On the other hand, while Joel Spolsky never misses an opportunity to mention Fogbugz (and I can’t really blame him, it’s what his company does), I don’t think he has much to gain from a commercial standpoint with this kind of article. I do think that he’s exaggerating his points a little bit in order to be provocative and generate indirect publicity and I’m pretty sure that Fogbugz is a lot more tested than he wants us to think.

But overall, I’m happy to see the pendulum beginning to swing the other way. Instead of advocating religious methodologies, I want to see thought leaders suggest common sense and judgment and show flexibility when it comes to recommending technologies. I think we will have reached this point when an Agile advocate comes to see me, takes a look at my team, chats with them a little bit and then tells me “I think stand-up meetings will be useful to your team but you should probably not use pair programming”.

Now, this is true agility.