Kent Beck’s Mother Doesn’t Work Here, and Neither Does Yours


Way back in 1997, when it was still just fine for a dude to rock a shiny bowling shirt and bleach the crest of his bangs, Kent Beck identified a three-step process for writing great code. Likely a truer and more useful thing to perhaps have tattooed on one’s self than ninety percent of the other ink permanently installed during the Clinton administration, it went a little something like this:

  1. Make it work
  2. Make it right
  3. Make it fast

Sakes, does that ever roll off the tongue and come off punchy in a meeting. But, just so we’re all running our reader finger along the same page with regard to what each of those amount to:

  • Make it work means that the tests pass and the software functions as advertised.
  • Make it right means that the code has been refactored into something that you love so much that you wish there was a Clean Code Magazine and that they could come and interview you about it. You know. DRY, SOLID, readable and maintainable.
  • Make it fast means that the code is tuned for performance.

“Yeah, Jon, so, yeah. That’s fine for him and his pals in their Ivory Tower where they pair and write interfaces and invert dependencies and eat ice cream all day not that I’m angry. But our boss won’t let us do steps two and three. What does Kent Beck say about that?”

Well, I can’t speak for Beck. But I’d say we just found out why your code sucks.

Also: it is totally your fault.

Here’s why.

It’s easy to assume that these steps are supposed to happen at the lifecycle scope of a system, like phases in a project. As in:

  1. First, we spend six months getting the application to work.
  2. Then we go through the code with a slide rule, put some fresh tape on its glasses, and inflict a neckbeard wish-list that results in absolutely zero changes apparent to the user. If we’ve done it right.
  3. Finally, we go on stopwatch safari, hunting down for-each loops and parallelifying them. Also? Indexes.

And at long last the user has the very same feature (and bug) set that they’ve had for a year, except now all the nerds are happy and the budget is blown. Fowler be praised.

I suppose it’s possible to sell this approach to the patron of your sundry bracketed text files and persuade them to loosen their purse strings for months on end with nothing to show for it but QUALITY CODE. But it’s not likely. Nor should we expect anything of the sort—in fact, it’s bad business, and if you’re working for someone who is kosher with that schedule, they are a fool with whom said purse will soon be parted.

Don’t ask, don’t tell, and the hidden fourth step

In any case, from the non-nerd perspective, there is exactly one step to writing great code:

  1. Make it work

Make it right and Make it fast have nothing to do with anyone who isn’t slinging code. Heed another Clinton-era gem here: don’t ask, don’t tell. Trust me, you’re not Daniel Day-Lewis, and the users don’t care about your process. Steps two and three are assumed, rolled up into step one–of course it’s going to be right and fast.

And this leads us directly to how we can implement Beck’s method in the real world.

See, there’s a hidden fourth step that will help us remember where the first three belong. That fourth step? Check in the code.

That’s right. The three “Make it“s are not great hairy brushes with which to paint the entire codebase, one after the other. Rather, they represent an iterative approach to crafting each individual feature, before we can declare it done. So really, it’s:

  1. Make the feature work
  2. Make the feature right
  3. Make the feature fast
  4. Commit the code

Oh, and

  1. Tell the boss that you made the feature work

Our mother doesn’t work here, you guys. But if we make tidying up after our own sloppy click handlers a part of what we do every day, we can have our cake and refactor it too.



Mmm. Refactored cake.