The Simplification Playbook

QuestionWhich complexity can be removed at all?

The ideaFred Brooks divided the difficulty of building software into two kinds. Essential complexity belongs to the problem, such as tax rules or what a customer needs. Accidental complexity comes from how we chose to solve the problem: the tools, the handoffs, the workarounds and the history (Brooks, 1986).

Use it toAim every cut at accidental complexity. Essential complexity can be moved or reorganized, but not removed.

Watch forOwners tend to call their own steps essential. Ask what the outcome requires, not what the current system requires.

QuestionWhen I remove a step, where does its work go?

The ideaLarry Tesler, who designed software interfaces at Xerox PARC and Apple, argued that every process carries a core of complexity that cannot be removed, only moved between the system and the people who use it. The idea is known as Tesler’s law (Saffer, 2009).

Use it toFor every step you cut, name who does that work afterward. A good simplification moves essential work to whoever can do the work most cheaply, which is often software.

Watch forSelf-service can be a real simplification or a transfer of work onto the customer. Count the customer’s steps as well as your own.

QuestionHow simple am I allowed to make this?

The ideaW. Ross Ashby showed that a system can only keep control of as many different situations as it has different responses: “only variety can destroy variety” (Ashby, 1956). A process stays in control in one of two ways. The process can reduce the variety that arrives, or the process can increase the variety of its responses.

Use it toBefore you standardize a process, count the kinds of case that reach the process. To simplify, narrow what arrives (a clearer intake form, a narrower scope, saying no to some requests) before you cut the responses.

Watch forA process with fewer responses than the kinds of case it receives does not become simpler. The cases it cannot handle reappear as escalations and workarounds.

QuestionWhere should I divide the problem into pieces?

The ideaHerbert Simon observed that complex systems which last tend to be “nearly decomposable”: they divide into parts with many interactions inside each part and few between parts (Simon, 1962). David Parnas gave the rule for drawing the boundaries: put each decision that is likely to change inside one part, so a change touches one part only (Parnas, 1972).

Use it toGroup the steps and decisions that change together under one owner. Count the handoffs between groups, because each handoff is an interface that someone has to maintain.

Watch forBoundaries drawn along the organization chart rather than along the work can add handoffs. Melvin Conway observed that systems tend to copy the communication structure of the organization that builds them (Conway, 1968).

QuestionHow do I build the simpler version without breaking what works?

The ideaJohn Gall wrote that “a complex system that works is invariably found to have evolved from a simple system that worked”. He added that a complex system designed from scratch never works and cannot be patched up to make it work (Gall, 1975).

Use it toReplace a process one thin slice at a time, such as one type of case, one team or one region, from start to finish. Expand the change only after the slice works.

Watch forGall’s law is an observation from experience, not a tested law. Treat Gall’s law as a strong default rather than a proof.

QuestionIs it safe to remove this step?

The ideaG. K. Chesterton described a fence across a road. A reformer who can see no use for the fence should not remove it until they have found out why someone built it (Chesterton, 1929).

Use it toFor every step that nobody can explain, find the person or the incident that created the step. Many such steps guard against a problem that no longer exists, and those steps can go.

Watch forThe rule can become an excuse to keep everything. Set a date for the search. If nobody can name a reason by that date, remove the step in a way you can reverse.

What to checkOne customer record is essential. Three systems holding that record are accidental. The work of keeping the three in step falls on whoever reconciles them today.

The moveMove one business unit onto the surviving system first, and retire the others only after that unit runs cleanly.

What to checkEach clause was probably added after an incident. Find the incident before deleting the clause, and ask whether a single spending limit with discretion would cover the same cases.

The moveReplace many narrow rules with one limit and a named person who decides exceptions. Discretion gives the policy more responses with fewer rules.

What to checkAsk which metrics have changed a decision in the last year. The information bottleneck method (Tishby, Pereira and Bialek, 1999) formalizes the same idea: keep the information that predicts the outcome you care about, and compress the rest.

The moveKeep the metrics that changed a decision, and move the rest to a page people can open when they need it.

What to checkThe customers who used the feature still have the need. Without the feature, those customers do the work by hand or call support, so the work has moved rather than disappeared.

The moveCount the support contacts and workarounds after removal, not only the code you no longer maintain.

What to checkCyclomatic complexity (McCabe, 1976) counts the independent paths through a piece of code. Coupling and cohesion (Stevens, Myers and Constantine, 1974) measure how much the parts depend on each other.

The moveSplit the module so that each decision likely to change sits in one place, then measure whether changes touch fewer files.