In which our intrepid author makes a grievous error: disagreeing with Kent Beck. Or does he?

Before reading on, please read this article by Kent Beck. In it, he seems to be repudiating his former hopes that code can and should be “neat, tidy”, and says that code can only have three states, “near disaster, disaster, and unused”.

After painting what I consider to be a horrid and dangerous picture, he brings the story back around to some forms of tidying that “make sense” to him: implementation patterns, tidying first, and TDD. I have no trouble agreeing with those.

So read the article and think about it. My concern is that “near disaster” is a very precarious state, and “disaster” is almost always unrecoverable. I think it’s wise to stay well away from the abyss of disaster. With half the population of developers holding five or fewer years of experience, there’s a big force pushing toward disaster. I am concerned that “tidying” is too wimpy a word to do the job.

That said, as I look back on my half-century of experience, my teams and I have worked on a lot of code that never shipped. I didn’t know how to build software that was always shippable, and too many times, management ran out of patience before we got all the capability in that they needed. I think the majority of these problems were not due to keeping the code too neat and tidy. I frankly think it’s very difficult, nearly impossible, to keep the code so neat and tidy that it gets in the way of shipping.

It is possible to gold plate. It is possible to choose an architecture that you’re not capable of building. It is possible to choose a problem that is too difficult for the platform you’re using. It’s possible to choose a problem that you and your team are just not good enough to solve.

Is it possible to keep the code too clean? I’m sure it is. I could spend the next fifteen sessions improving the names in Invaders, and that would be bad. I’ve rarely seen that happen, by which I mean never. In practice, there’s very little danger that your code will be too clean.

If I had to boil down what I (think I’ve) learned over the past half-century, it would go like this:

  1. Build something fully usable and shippable, however tiny, in the earliest days of your effort.

  2. Continue to add capability to it, keeping it usable and shippable.

  3. Ship it weekly, if not more often.

  4. Guide your addition of capability using feedback from your real users.

  5. Evolve the design and architecture as you go, keeping the system as well-factored as you possibly can.

As far as I can tell, the only way to do items 1-4, which keep you in business, is to do item 5, which keeps you from drowning in your own, um, effluent.

For me, “near disaster” is a good story, but it’s too close to “disaster” to be sustainable.

You should listen to Kent. He’s smarter than I am. I suspect if he and I were doing a joint video on this we wouldn’t disagree much. If we did disagree … well, you have to do as you see fit, whether you listen to us or not.