Effective process design
“A LISP programmer knows the value of everything, but the cost of nothing.” — Alan Perlis
This amusing epigram coined by Alan Perlis is a take on Oscar Wilde’s version (“A cynic is someone who knows the cost of everything but the value of nothing”). There’s also Rich Hickey’s version, removing the prefix about LISP (“…programmers know the value of everything but the cost of nothing”), alluding to how programmers like shiny-new-things, sometimes at the cost of simplicity. I want to suggest the idea that with respect to process design, it is people in general who know the value of everything, but the cost of nothing.
Organizations tend to have quite a bit of processes and rules, and these become more common as they grow. Things like a code review policy, travel policies, interview processes, expenses etc’. Anything that at some point was written down and agreed upon, accumulate.
On the one hand good process design can radically improve life in a society, e.g. traffic rules, so it’s clear why they’re so appealing. On the other hand — we’ve all been victimized at some point of our lives by a poorly designed process or legacy convention.
It is usually when people start thinking about the solution more than they think of the problem, where this starts to go awry.
Usually this is how it goes:
- Within some aspect of work, people interact in a relatively benevolent chaos. Maybe some do things a certain way, while others do it differently. Maybe they coordinate, maybe they don’t. Maybe there are unspoken rules, or unwritten rules, or maybe it’s just common sense that determines how things are done.
- One day, something bad happens… a bug in production, a duplicated spend, someone was offended, someone made a costly mistake, people were doing the same thing, someone forgot to turn something off (or turn it on…).
- Alarmed, people with sufficient authority get together and come up with rules to prevent the bad thing from happening again.
- Companies tend to share these rules as best practices.
- Sometimes other companies make it their business to enforce such practices, giving some stamp of approval.
- Companies only make business with companies that have these stamps of approval, making these best practices somewhat immortal.
When processes are thought out, there is typically a concrete waste or harm happening, while the cost of the process itself is ephemeral, imaginary at this stage, sometimes not even considered. So first observation — it’s more intuitive, familiar and easy to add a process rather than remove one.
This recall oriented thinking can be thought of as — you cast a large net to catch all fish in existence, being less concerned with how much seaweed and plastic bottles you fish out (precision).
It is also (unfortunately) typical that the designers of the process are not always the ones fulfilling it, or the process designer always fulfills one role in the process, not experiencing what it’s like to be in the other role’s shoes.
Sometimes we are inclined to seek order for the sake of order itself, finding the sheer ambiguity of things troubling, regardless of whether they present a problem or not.
So in time things start to add up, and not all that adds up adds value. If we aren’t careful, our organization will develop aging symptoms: bureaucratic absurdities, people acting against their common sense, diminishing returns on hiring, drop in morale and so on.
To keep this at check there should be two opposing fundamental forces — one to prevent harm/reduce waste, and another to minimize the model — the complexity of rules and processes that exist and how easy they are to follow.
Because this is easier said than done, I collected some principles I use whenever I’m facing mine or others’ instinct to “solve something“once and for all”. You can think of these as a a bunch of mental tests to recite whenever considering a proposition.
Timing — prefer coming up with a process after something bad/inefficient happened, not before
It’s very hard to predict the future. If you can withstand something happening once or twice and learn from it, you want to let it happen so you can be sure you’re not solving the wrong problem, and that your solution fits the context.
Aka “you ain’t gonna need it”.
This rule has some exceptions:
- The cost of the thing happening only once cannot be withstood.
- Everyone involved believes it is extremely probable that something bad will happen.
- You’ve been in an organization where things worked well this way and this is your basic framing of how people should work.
The corollary here means that if you’ve only heard/read about some fancy process, it’s not a good enough reason by itself to apply it. The pain must be yours and the solution must fit the context you are in.
Classic example: “Test coverage should be 100%”
Classic counter-example: “Look both ways before you cross the street”
Correctness — why the process solves the problem should be logically easy to verify
Not — “I believe this would cause people to behave in a wanted way” or “it will raise awareness”, but concrete analysis of cases and seeing how they interact with the process.
Classic example: if we increase jail time for drug offenses, we will reduce the number of addicts in our streets. Well, maybe, but the problem and the solution are so indirectly related that we need to have pretty good science to back it up.
Classic counter-example: We keep having bugs in production that are prevent our server from starting up. If we add a startup check to our CI/CD it would be impossible to submit code that causes this. This is easy to validate logically.
Minimality — start lean and minimal, adding things when new events transpire
If two things prevent a bad thing from happening, go for the simpler one. It’s easier to add stuff than to remove them.
Watch out for redundant steps and after you’ve written something down, try to see if some stages can be removed.
Beware of premature generalization — lack of structure is superior to bad structure. If you aren’t sure you generalized the problem correctly, it is perfectly valid and even smart to wait for more examples (keeping the problem alive).
Process design is not a one-turn game, but a recurring iterative game with many moves.
Cost-efficiency — is it worth it?
Evaluate, as explicitly as possible, the process cost instances applied × cost per instance) vs the expectancy of a bad event (probability it happens × its cost).
If the latter isn’t higher than the former, then you should come up with a less costly process or keep the problem alive for the time being.
Classic examples:
- limit every car’s speed to be below the threshold that can hurt a human being on impact. Works but at what cost.
- A drug has been found to be harmful to human society — ban all drugs.
Automation — manual process often means guilt + no real process
I cannot stress this enough. I’ll even venture to say that the vast majority of non-automated processes tend to fail and should be avoided entirely. If you can’t automate the enforcement, telling people things will not help. People have a lot on their minds. If you do get them to remember, rest assured this is a zero sum game on their gumption and ability to enter “flow state”. Also terrible — different people vary with their attention to detail and conformity, and once you have a process not everyone follows, and people start to check on one another, this is unpleasant for everyone.
Classic example: Software engineering without CI/CD sucks.
In conclusion, it’s human nature to focus on solutions. We need to be aware of this and focus our attention on the problem instead. If you’re at a discussion about a new process, make sure to start with learning about the problem, and invest enough time in that. I hope the principles above will help you make life better for you and those around you.
Thanks for reading!
