ATTENTION, PEOPLE WHO HAVE PUT “BROOKS’S LAW” IN A SLIDE DECK INSTEAD OF A PLAN!
PEOPLE WHO HAVE ANNOUNCED “CONWAY’S LAW” WHILE POINTING AT AN ORG CHART AS THOUGH IT HAD JUST CONFESSED! PEOPLE WHO HAVE CALLED A METRIC “GOODHARTED” BECAUSE THE GRAPH DEVELOPED A PERSONALITY!
Are you tired of not having a famous person’s surname ready for every technical meeting?
Have you spent another sprint saying “Parkinson’s Law” about a deadline, “Brooks’s Law” about hiring, “Amdahl’s Law” about hardware and “Conway’s Law” about architecture — then going home with exactly the same plan, only now it has quotation marks around it?
Then congratulations.
You qualify for the Five Number One Rules of Using Famous Laws Without Becoming One, the complete anti-slogan delivery system containing not one, not two, but FIVE NUMBER ONE RULES.
“Wait,” you’re shouting into the incident channel, “they can’t all be Number One!”
That’s exactly what Big Numbering wants, while it sells one dazzling line as a substitute for examining the system.
Named laws age in specialist ways.
The original wording can be wrong in the slide deck.
A correct quotation can still hide the mechanism.
A real mechanism can still have a boundary.
A boundary can fit the old system and miss the current one.
And a perfectly scoped, entirely current claim can still sit in a wiki doing absolutely no work at all.
Goodhart’s monetary observation can’t plan a staffing change. Brooks’s staffing warning can’t calculate a serial bottleneck. Amdahl’s formula can’t reveal an organisation’s communication paths.
No surname gets to impersonate the architecture.
So here they are.
Five rules.
Five Number Ones.
No substitutions. No law-shaped wallpaper. No declaring victory because a dead engineer has been summoned into the meeting by possessive apostrophe.
RULE #1: FIND THE ORIGINAL CLAIM
Introducing QUOTE-O-MATIC 1975™, the desktop monument converting every sentence ending in “Law” into a sticker for a laptop nobody opens.
Start with the actual claim, its original venue, and the problem it was addressing.
This isn’t a demand for a wax-sealed first edition before lunch. It’s a demand to stop treating the neatest later paraphrase as evidence of what somebody said.
Goodhart is the showroom model.
What Goodhart wrote, in a 1975 paper on UK monetary policy, is that an observed statistical regularity tends to collapse once pressure is placed on it for control purposes. His target was a specific monetary aggregate that stopped tracking the useful thing once policy started aiming at it.
The famous version — “when a measure becomes a target, it ceases to be a good measure” — is Marilyn Strathern’s compression, written in 1997, about university audit culture.
That’s not pedantry with a tiny hammer. It changes the question you ask.
A dashboard metric isn’t automatically corrupted because somebody looked at it. The concern is control pressure reshaping the behaviour that made the relationship informative in the first place.
So when a team starts optimising a deployment metric, ask what action it now rewards, and whether it can still indicate the condition it used to track. Very different investigation from “someone is watching it, therefore it’s ruined.”
Parkinson needs the same handling. The 1955 essay opened with work expanding to fill the time available — then made a satirical argument about Colonial Office staffing growing while the territory it administered shrank.
And the famous committee threshold of about twenty belongs to a mock-scientific “coefficient of inefficiency.” It is a joke doing a job, not an engineering constraint handed down on stone tablets.
The popular sentence is not the original system.
Attribution isn’t ornament. It’s where the missing variables are hiding.
RULE #1: NAME THE MECHANISM, NOT THE SLOGAN
NOW AVAILABLE: BROOKS’S LAW: THE ACTION FIGURE!
Pull its cord and it says adding manpower makes it later! It does not explain whom to train, who must coordinate, or which work can be divided.
Perfect for management.
Brooks wrote in 1975 that adding manpower to a late software project makes it later.
He also called that sentence an “outrageous oversimplification,” in his own book, on purpose.
That warning label isn’t a garnish. It’s there because he immediately supplied three mechanisms: new people need ramp-up from people already busy, communication overhead grows combinatorially with headcount, and some work simply cannot be partitioned.
Nine months remains nine months, however emotionally expressive the staffing spreadsheet becomes.
So a late project doesn’t receive a mystical no-hiring stamp. It receives a diagnosis.
Is the remaining work divisible? Who trains the arrivals? What coordination paths appear as the team grows?
Later studies found the effect real but sensitive to the project moment and to how divisible the remaining work was.
The slogan says no. The mechanism says where to look — and those are different services.
The same distinction rescues code review from its own tasteful little cargo cult.
Formal Fagan inspection is not an ordinary pull-request comment session wearing a necktie. It includes planning, individual preparation, a formal meeting, rework, and follow-up verification — and its cited 80–90% defect figure belongs to that entire process.
Lightweight review data describes a completely different mechanism: 200 to 400 changed lines over 60 to 90 minutes.
Quoting the first number while running the second is how a team ends up disappointed in its own diligence.
A principle is usable only after it names the force that makes the result happen.
Without the causal story, the slogan isn’t a tool. It’s a refrigerator magnet with executive privileges.
RULE #1: CHECK WHETHER THE CLAIM HAS A VARIABLE OR A BOUNDARY
BEHOLD INFINITY-PLUS™, the server upgrade promising limitless speed because the word “parallel” has appeared in a procurement meeting.
Some named laws are observations. Some are satire. Some are equations.
Treating all three identically is how a team converts “we have a law for that” into a reason to stop asking what changes the result.
Amdahl is the mercifully non-mystical case, and the arithmetic is worth doing out loud.
Take a workload that’s 95% parallelisable. Make the parallel portion infinitely fast — free processors, unlimited cores, no coordination cost.
Total speedup: 20×.
That’s the ceiling. Not because the remaining 5% is being difficult, but because it’s still there, running in sequence, while everything else has finished.
Which gives a performance discussion an actual job. Find the serial fraction. Is it database work? A lock? A dependency? A human approval? An integration step?
Then decide whether more parallel capacity touches it at all — because frequently it doesn’t.
Invoking Amdahl’s Law without measuring that fraction is the technical equivalent of waving at a map from a moving car.
Some boundaries are evidentiary rather than algebraic. Metcalfe’s possible-connection count is exact combinatorics, but the claim that network value scales as n² is contested — with a 2006 argument for something closer to n·log(n).
The formula exists. The conclusion about value remains unresolved. Those aren’t the same thing.
And any number needs the process that produced it. Reviewers moving above roughly 500 lines an hour showed reduced defect detection; effectiveness degraded after about 60 continuous minutes.
Useful operating boundaries from a well-cited but dated dataset. Not universal speed limits issued by the Department of Reading Code.
A number does not end judgment. It tells judgment where the edge is.
The law isn’t “parallelise more.” The law is “find what refuses to parallelise.”
RULE #1: TEST IT AGAINST THE CURRENT SYSTEM
FROM THE MAKERS OF “CONWAY’S LAW EXPLAINS EVERYTHING” comes ORG-CHART ASTROLOGY!
Feed in a reporting line, receive a confident prediction about every API, merger, and kitchen renovation.
Conway’s actual thesis is more useful than that product and far less supernatural.
He wrote in 1968 that organisations designing systems are constrained to produce copies of their communication structures.
Not that every box in an org chart sprouts a matching microservice overnight. That communication and coordination constraints shape technical decomposition.
The named empirical support has a scope worth respecting. MacCormack, Rusnak and Baldwin compared tightly coupled commercial teams against loosely coupled open-source ones and found strong evidence for mirroring — the commercial products were measurably more tightly coupled.
That’s evidence from a studied comparison. It isn’t a royal decree that any reorganisation cures coupling, or that a distributed team is automatically modular because it owns more video-call backgrounds.
So test the present system instead.
Where do decisions wait? Which repository boundaries force the same people to coordinate? Which interfaces need synchronised changes?
If communication structure and product structure are pulling against each other, name the specific coupling — then change a boundary, an interface, an ownership arrangement, or a work sequence.
A law earns its keep when it helps select a change. Not when it makes the diagram feel observed.
Current practice has claims to test too. DORA defines continuous integration narrowly: merges to trunk at least daily, with an automated build and test run against them at least daily, ideally on every merge.
Its reports associate that specific pattern with higher deployment frequency and more stable production systems.
A team merging long-lived branches weekly is certainly building software. It is not operating the pattern behind those findings, and shouldn’t expect the findings.
A law transfers only after the current system supplies its mechanism and its conditions.
The map is old. The terrain has every right to have changed.
RULE #1: TURN THE LESSON INTO A PRACTICE YOU CAN OBSERVE
THIS IS THE ONE THEY TRIED TO HIDE IN THE FOOTNOTES!
SLOGAN-TO-RITUAL 5000™ converts a wise sentence into calendars, pull requests, build logs, and the faint horror of having evidence.
A famous law is alive only if some current ritual would reveal its absence.
That’s the whole test. Not whether the team can recite it in a retrospective. Not whether its author has a page on the internal wiki.
Can somebody inspect a decision and see the mechanism being handled?
For Brooks: make staffing proposals name the onboarding work, the new communication paths, and which remaining work is actually divisible.
For Amdahl: make performance proposals state the serial fraction before promising a speedup.
For Conway: make architecture review identify the communication path and interface producing the coupling.
Those aren’t bureaucratic tribute payments to dead authors. They’re small tests against the specific failure each claim names.
For review, put it in the pull request itself. Flag diffs above the team’s chosen threshold. Record review duration. Avoid treating an hour of continuous reviewing as proof of heroic attention rather than diminishing returns.
And rotate assignment instead of routing everything to the fastest approver — because modern review also carries knowledge transfer and team awareness, which a single fast reviewer quietly eliminates.
For CI, inspect the branch and the clock. Daily trunk merges, automated runs, and a suite fast enough that people actually wait for it.
A 45-minute suite still runs. But its feedback arrives late enough that developers run it less often, and more changes pile up after the last known-good state — which is the failure, arriving by a slower route.
Feature flags let small incomplete changes merge. They also create a removal obligation.
No free sequels. No return of the flag from the dead in season nine.
A law becomes practice when a routine can show whether the mechanism is present.
If nothing observable changes on Monday, the law was only décor on Friday.
BUT WAIT, THERE’S MORE!
“What if the law is satire?”
Same rules. Parkinson and the Peter Principle don’t become useless because their authors were joking. Recover the claim, find the mechanism, and don’t pretend a joke supplied a universal threshold.
“What if the law has a formula?”
Same rules. An equation gives you variables, not values. Measure the serial fraction before letting it into a budget meeting.
“What if everybody says Conway’s Law is proven?”
Same rules. Name the actual comparison, and respect its scope.
“What if the pull request already has a famous-law checklist?”
Same rules. Check the changed lines, the pace, the assignment, the trunk merge, the automated run. A checkbox is evidence only when it points at something that happened.
“What if a platform, a team, or the report changes?”
Same rules.
The details change.
The architecture doesn’t.
THE FIVE, WITHOUT THE QUOTATION MARKS
Find the original claim — its wording, its venue, and the problem it was actually about.
Name the mechanism that makes the effect happen, before the slogan decides anything.
Check for variables and boundaries, then measure them rather than treating a number as a blessing.
Test the claim against the current system, and against the scope of the evidence behind it.
Turn the lesson into an observable practice that can visibly fail.
DO THIS BEFORE THE NEXT STATUS MEETING
Tonight, find one famous law living in a slide deck, an architecture decision record, or a comment beginning “as everyone knows.”
Copy the exact sentence being used. Then go find the original wording.
Beside it write three things: what the original actually observed, calculated or satirised; what mechanism made the result plausible; and what variable, boundary or studied population limits it.
Then run it through your present system.
If it’s Brooks, list the ramp-up work and the coordination paths before the staffing request goes in.
If it’s Amdahl, measure the serial fraction rather than requesting processors on vibes.
If it’s Conway, draw the actual communication path producing the coupling.
If it’s code review or CI, look at the real numbers — changed lines, review duration, merge frequency, suite runtime.
Finally, add one field to whichever ritual matters: which named principle is this meant to test, and what observation would show it isn’t operating?
That isn’t paperwork for its own sake. It’s the moment a famous law stops being a sentence delivered by a ghost and becomes a way for living engineers to notice reality.
For the low, low price of checking what the law actually says, the complete Five Number One system is yours.
No subscription. No marble bust. No emergency purchase of a framed quotation in a sans-serif font.
And if you act now, we’ll include the only upgrade that survives the next fashionable slogan, at no additional charge:
a mechanism that can be checked.
Operators are no longer standing by.
The operator is the person who has to make the system work.