Some things I know before I can explain them. I sit in a project meeting and feel that adding more people will probably make things slower. I see a deadline with too much room around it and know the work will expand to fill it. I look at an architecture diagram and quietly suspect it is less a technical design and more an organizational chart wearing a hoodie.
For a long time, these were just gut feelings. Then I discovered they have names.
Parkinson’s Law. Brooks’s Law. Conway’s Law. Murphy’s Law. A whole collection of observations that sound clever because they describe something painfully familiar.
That is useful. Not because these laws are always true, and certainly not because quoting them makes you automatically right. That would be convenient, but also slightly unbearable. They are useful because they act as warning labels.
Below are eleven of these “laws”, each with a short practical warning. Use them as thinking tools, not as proof. A named pattern can sharpen your judgement. It can also become a shortcut for not thinking.
The trick is knowing the difference.
- Parkinson’s Law
Work expands to fill the time available.
At work, this is why a two-week task often becomes a two-week task, even when it could have been done in three days. Calendars are excellent at creating gravity.
The mistake is thinking the solution is only tighter deadlines. Sometimes it is. But often the real solution is a smaller scope, clearer ownership, and fewer people polishing things nobody asked for. - Brooks Law
Adding people to a late project often makes it later.
A project is slipping, so management adds more people. That feels logical. More hands, more progress. In reality, the existing team now has to onboard people, explain decisions, split work, align interfaces, and attend more meetings. Delivery slows down before it speeds up, if it speeds up at all.
They use it as a lazy argument against hiring or scaling teams. Brooks’s Law does not say that more people are always bad. It is saying that people are not interchangeable delivery units.
Before adding people, check whether the work can actually be divided. If the bottleneck is architecture, decision-making, or unclear scope, extra people mostly add coordination debt. Alternatively, you can say: “While it takes one woman nine months to make one baby, nine women can’t make a baby in one month.” - Hofstadter’s law
It always takes longer than you expect, even when you take Hofstadter’s Law into account.
Complex work looks manageable in a planning session. Then reality arrives. Dependencies appear, assumptions break, integrations behave as expected, and the “small change” turns out to affect five systems and three teams.
They use it as a joke instead of improving estimation. “Everything takes longer anyway” is not a planning method. It is a surrender with a clever name.
When work is complex, do not only estimate the task. Estimate the uncertainty around the task. The unknowns are usually where the project budget goes to disappear. - Murphy’s Law
If anything can go wrong, it will go wrong.
A release depends on one undocumented script, one person who is on holiday, one API that nobody has tested properly, and one assumption from a meeting that nobody wrote down. Naturally, the problem appears at the worst possible moment. Systems have a talent for theatrical timing.
They treat it as pessimism. It is not pessimism. It is risk awareness. Pretending nothing will go wrong is not optimism either. It is poor engineering with better lighting.
Design for failure before failure designs your agenda. Reduce complexity, test the boring parts, document the fragile parts, and never confuse “it worked once” with “it is reliable.” - Conway’s Law
Organizations tend to design systems that mirror their communication structures.
A fragmented organization produces fragmented systems. Every department gets its own tool, its own database, its own definitions, and its own version of reality. The architecture diagram starts to look suspiciously like the org chart.
They quote Conway’s Law as if naming the problem fixes the architecture. It does not. Saying “this is Conway’s Law” in a meeting may make you sound observant. It will not untangle the spaghetti.
If you want better systems, look at team boundaries, ownership, incentives, and communication paths. Architecture is often organizational design with APIs attached. - Moore’s Law
Computing power tends to increase rapidly over time.
Teams assume that tomorrow’s hardware, cloud capacity, or platform improvements will compensate for today’s inefficient design. Sometimes waiting helps. Often, it just postpones a structural problem.
They use it as an excuse for waste. “Technology will get faster” is not the same as “we can ignore performance, cost, and energy use.”
Do not use future capacity to justify present laziness. Faster infrastructure can hide bad design for a while, but cloud bills, energy use, latency, and operational complexity have a way of sending invoices. - Fitts’s Law
The time needed to reach a target depends on its size and distance.
In user interfaces, the big visible button gets used. The hidden correct option does not. In organizations, the easiest process wins, even when it is not the best process. People follow the path with the least friction.
They treat it as only a UI design law. It is bigger than that. In work systems, whatever is easiest to reach becomes the default behaviour.
Make the right action easy. If the official process is buried in a SharePoint folder and the bad workaround is one Slack message away, do not act surprised when the workaround becomes the process. - Postel’s Law
Be conservative in what you send, and liberal in what you accept.
Systems need to communicate with messy real-world inputs. APIs receive slightly imperfect data. Integrations deal with inconsistent formats. Humans, being humans, enter things in ways no specification writer imagined.
They interpret “be liberal in what you accept” as “accept everything and sort it out later.” That later usually becomes a data quality problem, a security issue, or a migration nobody wants to touch.
Tolerance is useful. Ambiguity is expensive. Accept imperfect input when needed, but validate, log, clean, and standardize it as close to the source as possible. - Pratchett’s law
Chaos always wins, because it is better organized.
A carefully designed plan meets real users, legacy systems, budget changes, unclear ownership, vendor delays, and one executive with a new priority. Chaos does not need approval. That is one of its competitive advantages.
They use it as an excuse to stop planning. But the point is not that planning is useless. The point is that rigid planning is fragile.
Plan for adaptation, not perfection. Build feedback loops, decision points, and room for change. Otherwise, the plan becomes a museum piece: nicely structured, rarely useful. - Godwin’s Law
As an online discussion grows longer, the chance of a comparison involving Hitler or Nazis increases.
Not always literally, thankfully. But the pattern appears whenever discussions escalate from substance to extreme comparisons. The longer a debate runs without structure, the more likely people are to reach for moral theatre instead of useful argument.
They use it to shut down uncomfortable comparisons automatically. That is too easy. Some historical comparisons may be relevant. Many are just lazy escalation.
When a discussion becomes performative, bring it back to evidence, definitions, and consequences. If the comparison is doing more emotional work than analytical work, it is probably not helping. - Hahnemann’s Law
Things often sound more convincing when wrapped in old language, authority, or tradition.
A weak idea becomes more impressive when it gets a framework name, a Latin phrase, a maturity model, or a consultant diagram. Suddenly, common sense has a logo and a day rate.
They mistake impressive language for evidence. A concept can sound elegant, established, and profound while still being wrong, untested, or useless in practice.
Do not trust an idea because it sounds intellectual. Ask what evidence supports it, where it fails, and what happens when you apply it in the real world. Everything sounds better in Latin. That does not make it true.
These laws are useful because they compress experience into a sentence. That is also why they are dangerous. A law is not evidence. A clever phrase is not a diagnosis. And quoting Conway’s Law does not magically fix your architecture. Sadly.
Use these laws as warning labels, not as proof. Thanks for reading, and I’d love to read your own Laws as a comment on this post.
Discover more from Pragmatic Thinking by Robbrecht van Amerongen
Subscribe to get the latest posts sent to your email.
