Last week I wrote a blog entitled The Startup Trap in which I lamented the unfortunate tendency of developers in a startup to cast their disciplines aside in order to maintain the “high” generated by the illusion that effort is speed. I specifically mentioned TDD as one of those disciplines that startup developers sometimes eschew.

The response in support of the blog was gratifying. The response in denial (Yes, that’s the right word) of the blog was expected; though I was somewhat surprised by the vehemence and amplitude of the various pejoratives, barbs, insults, and other ad hominem statements. I suppose that people who are addicted to a “high” do not take kindly to those who challenge their ability to justify and maintain that “high”.

One of the most common threads, amongst the more reasonable of the complaints, was this:

In a startup, the business model is more important than the code.

This is correct; but the initial predicate is superfluous. The business model is always more important than the code. Great code, that doesn’t make or save money, isn’t very interesting to businesses.

The business model argument, correct though it may be, is irrelevant to my original point. Coding disciplines, including TDD, do not impede the discovery of the business model. Or to say this more succinctly, TDD does not slow you down.

Indeed, all of the complaints against my blog boiled down to the same invalid assumption: TDD is too slow.

That’s BS. At least it’s BS for me. TDD does not make me slower, it makes me faster. It makes others I know faster too. I presume that it could make everyone faster.

I’m not going to explore the reasons for that speedup here. There are many other articles, books, and blogs that try to explain it. For now I’ll just fall back on the old saws: Slow and steady wins the race. Anything worth doing is worth doing well. Sat ci sat bene. (It’s done fast enough when it’s done well.) Or to quote Brian Marick, “In code, it never pays to rush.”

As an example of one of these strange arguments about the business model, consider Greg Young’s response. This is a nice story about a business opportunity, the two week effort to make a Minimum Viable Product (MVP), and the subsquent 9 months of effort to re-do that code “right”. His point was that the code was profitable after two weeks, and scarcely any more profitable after the nine month effort; so the nine months was a waste.

Of course he’s right. The two weeks were what counted. The nine months were a giant pud-pull. Those nine months would have been better spent on something more profitable.

The logical flaw in Greg’s argument is the presumption that it would have taken him longer than two weeks to get the MVP done if he’d been using good disciplines. I reject that presumption entirely. I believe Greg could have gotten that MVP done in two weeks or less using good disciplines. Moreover, the resultant code would likely have been far more amenable to being improved by another two or three weeks of reasonable effort.

Now let me say this more directly. Good disciplines don’t slow you down. Indeed a discipline that slows you down is not a good discipline. TDD is a good discipline.

TDD does not take a two week MVP effort and turn it into nine months of auto-stimulation. Nor does refactoring. Nor does SOLID. Nor does pair programming. Nor does continuous integration. Nor do any of the other good disciplines out there.

Getting done right does not mean getting done slow. Getting done right means getting done fast. You will go faster if you do things right. You will go faster if you come down off the “high” generated by the illusion that effort is speed. You will go faster if you calm down, follow your disciplines, and refuse to rush.

Story Time

Greg told the story of his two week MVP. So now let me tell you the story of Langton’s ant.

The year was 2002 or thereabouts. James Grenning, I, and half a dozen Thoughtworkers were at an airport in New York waiting for a delayed flight back to Chicago. We’d been attending one of the early XP Universe conferences. James and I were in our early fifties. The TWers were all in their late twenties or early thirties.

In that conference, Kent Beck gave the closing keynote on the topic of emergent behavior. As he spoke the screen behind him showed a series of black and white pixels crawling around in a random way. At the end of his talk, as he made his final point about emergent behavior, the random nature of the pixels suddenly congealed into a repeating pattern that started at the center of the screen and crawled its way to the upper right corner. Kent said the algorithm was: Langton’s Ant, a simple cellular automaton with just two rules:

• At a white square, turn 90° right, flip the color of the square, move forward one unit
• At a black square, turn 90° left, flip the color of the square, move forward one unit

James and I had just ordered Gin and Tonics from the airport bar and returned to the waiting area, when we saw a group of the TWers frantically working on their laptops. We asked someone what was going on, and were told that they were racing to see who could implement Langton’s Ant quickest.

James and I looked at each other, nodded, opened a laptop, and quietly began to pair-program. We followed our disciplines, wrote test-first, kept the code clean, got it working after a few minutes, and then closed the laptop. We looked up, and the young twenty-thirty-something TWers were still expending copious energies in a fit of frantic coding. The frenzied intensity of their effort, driven by the panic of potential loss, was evident in their gestures and expressions. We, the two fifty-something programmers, smiled, clinked our Gin and Tonics, and sat back to enjoy the show being put on by all those young turks who never even guessed that they had been calmly bested by two of their seniors who had the experience and wisdom to know that the only way to go fast is to go well.