Code Anarchy

Superstition-Driven Development

Apparently, Agile is dying. Can software survive without Agile?

If TDD succeeds, we’ll get what we want – working software.

But will we?

Unit tests are great at catching “expected” bugs: bugs you’ve seen before, and others you think might be likely. Unit tests have a very narrow focus on specific areas of your program, though. They’ll test the crap out of individual functions and objects, finding bugs your customers can’t encounter because they’re only triggered by your tests, never your program. At the same time, they’ll totally miss other bugs your customers will see.

Unit tests are useful, but they’re no Holy Grail.

Research actually suggests we should be obsessing over code reviews, if anything:

More generally, inspections are a cheaper method of finding bugs than testing; according to Basili and Selby (1987), code reading detected 80 percent more faults per hour than testing, even when testing programmers on code that contained zero comments. This went against the intuition of the professional programmers, which was that structural testing would be the most efficient method.

Having someone else look over your code catches bugs quite a bit faster than writing automated tests will.

So what’s with the obsession with test-driven development (or Agile, for that matter)?

One factor is that anecdotes are convincing. There are plenty of people who will be glad to tell you how TDD saved their projects. All they really know, though, is that they used TDD (or some other bit of methodology) and it worked out for them. There are other people who will tell you it turned out to be a big waste of time at best.

They must’ve been doing it wrong though. If they got it right, it would’ve worked out… right?

This is superstition, not reason. Parroting unproven, unconditional advice is the cancer that’s killing Agile.

Well, that and thinking there’s a methodology called Agile in the first place. Have these people even read the Agile Manifesto? People over process, yo!