“So if I have an idea, first I have to write up a spec, then get that spec reviewed and prototyped, then get the work scheduled into a sprint, then code it up, get it peer reviewed, then put it through quality assurance, then get any migrations checked, prepped, run and verified, then maybe I can ship my idea?”

“That’s the full process, yes”

“So mean time from idea to shipping is, what, six months?”

The new girl is understandably shocked. She has been coding for a decade and has managed to ship functioning code without all these steps.

“But I just want to fix a typo!”

“That’s the process” her new manager says, “and it works. We haven’t shipped breaking changes in three years”

I’m lucky: I’ve never worked anywhere like this, but I can see how it happens, and it happens with the best will in the world.

Protect the HEAD

What is process? At its best, it is the codified learning of every expert who has ever influenced a team of people. Process is a safety net, a list of guidance for how to beat certain predicaments. It’s a recipe, an anchor to hold fast to when the seas are stormy.

Every process is a reaction to a threat—real or perceived. A bad thing happens, we try to work out what caused it, and we create a process to protect against the causes occurring again.

This is a Good Thing. Without this pattern (which, itself, is a process), we would never learn from past experiences. Everyone would have to learn lessons for themselves, and while this may be the best way to learn in an ideal world, learning this way “in production” is something to be guarded against.

You don’t teach brain surgery by trial and error.

What about rocket surgery?

“Too much process” is a phrase I hear a lot. Hell, I say it as often as I hear it. But it’s nonsense. It’s like saying “too much experience”. “Too much” when compared to what, precisely? And besides, what I hear being complained about isn’t process: it’s ritual.

Consider the conversation we heard earlier. Why is a spec necessary to correct a typo? What even constitutes a spec? If I scribble the typo on the back of an envelope, is it a spec? What about “quality assurance”? What does that actually mean?

A useful process carries with it not just the what, but the why. Why are we bound to write a spec? Why do we hand over to someone else for quality assurance? To be able to answer these things is the first step in having a process that adds something. To be unable to answer these things is to have a ritual: a series of talismans to ward off the dark spirits of Production Incidents, Downtime and Legal Action.

Since we’re defining things, what do I mean by “able to answer”? Does “that’s the way we’ve always done it” count? What about “because we shipped bad code the last time we skipped that”?

To have a useful process, you should be able to swap any part of the process with something different that solves the same problem. In other words, you need to be able to frame the process in terms of the problems being solved. The practical steps, then, are just possible answers to those questions.

The process above is really just:

• do you understand the problem?
• do other people agree with your understanding?
• can you solve the problem?
• did you break anything?
• did you forget anything?

The questions are the important part of the process. Without those, you’re just wearing coconuts on your ears and waiting for the planes to bring those sweet, sweet crates of plenty.

Day of Judgement

I’ve watched people hide behind process. I’ve done it myself. Process is comfortable, and it becomes habit. It becomes a thing that you use to cover your arse, or that you fear not following. Nobody ever got sued for following process, Godwin notwithstanding.

But one of the easiest ways to turn process into ritual is to overstretch it. Remember, process is a tool. It’s a recipe for beating certain specific problems. Overstretching processes to apply where they aren’t needed is like using the handle of a screwdriver to bash in nails. It works, but it’s not why you bought the screwdriver.

If your job has not yet been replaced by a shell script, it is for a single reason:

Process does not replace judgement.

For process to be wielded effectively, judgement must be wielded too. If you don’t understand the why of a process, you shouldn’t be using it without supervision. Similarly, if you do understand the why of a process, you should be using it to smash through pointless ritual.

Fixing a typo doesn’t need a spec, but it does need you to go and make sure that it isn’t an intentional pun to give character to the prose, or that you should be using the new localisation system to fix it.

Or maybe it doesn’t need any of that, and the step is entirely redundant.

For process to add value, it needs to be challenged, to be forged in the fire of continual questioning. When faced with any new process, your first instinct should be to dig in and understand the why.

That’s really the only ritual you should need.