13 Laws of Software Development

Every developer and manager accumulates heuristics over time — patterns that predict how projects behave, why teams slow down, and where metrics go wrong. Below are thirteen of the most practically useful ones, translated and adapted from Anton Zaides' original compilation.

1. Parkinson's Law

"Work expands to fill the time allotted for it."

Set a two-week deadline and the task takes two weeks. Set a one-week deadline and, more often than not, it still gets done — perhaps with sharper focus and fewer gold-plated details. The lesson is not to set artificially tight deadlines to the point of causing burnout, but to be deliberate about time allocation. Loose, comfortable estimates tend to drift. Realistic, slightly challenging ones tend to improve quality by forcing prioritisation.

2. Hofstadter's Law

"Any task always takes longer than expected, even when you account for Hofstadter's Law."

This self-referential statement captures why software estimation is so persistently difficult. You add a buffer. The task still overruns. You add a bigger buffer next time. It still overruns. The reasons are structural: requirements change, unknown unknowns surface, integration problems appear only when components meet. Awareness of this law doesn't eliminate the problem, but it discourages overcommitting and encourages building slack into roadmaps deliberately rather than optimistically.

3. Brooks's Law

"Adding people to a late software project makes it later."

Fred Brooks articulated this in The Mythical Man-Month and it remains painfully true. New engineers don't become productive on day one. Existing engineers must spend time on onboarding, answering questions, and reviewing pull requests instead of writing code. Communication overhead grows roughly as the square of team size. The project almost always slows further before any benefit from additional headcount materialises. The correct response to a late project is almost never immediate headcount growth.

4. Conway's Law

"Organisations design systems that mirror their own communication structure."

If your frontend and backend teams barely talk to each other, their respective systems will grow apart. API contracts will lag behind actual usage. Deployment pipelines will be owned by separate groups with different priorities. The powerful corollary — sometimes called the Inverse Conway Manoeuvre — is that you can deliberately restructure teams to produce a desired architecture. Align team boundaries with desired service boundaries and the architecture tends to follow.

5. Cunningham's Law

"The best way to get correct information on the internet is not to ask a question, but to post the wrong answer."

People are far more motivated to correct an error than to respond to a genuine inquiry. This applies to code reviews, design documents, and technical discussions: a concrete (even deliberately imperfect) proposal attracts more useful feedback than an open-ended question. Post a draft, write a spike, propose a direction. The corrections that follow are often more valuable than any response to "what should we do here?"

6. Sturgeon's Law

"90% of everything is garbage."

Theodore Sturgeon made this observation about science fiction, but it generalises uncomfortably well to software features. Studies of feature usage consistently find that the vast majority of built features are rarely or never used. Most of what a team builds does not drive meaningful value. The implication is not despair but ruthless prioritisation: before building something, challenge whether it belongs in the 10%. Accepting that most ideas are mediocre is a prerequisite for focusing on the ones that aren't.

7. Zawinski's Law

"Every program attempts to expand until it can read email. Those programs which cannot so expand are replaced by ones which can."

Jamie Zawinski observed that software tends to accumulate features over time until it becomes something far more complex than it started as. Word processors gain email clients. Browsers gain operating-system capabilities. Chat tools gain project management features. At some point a simpler competitor emerges with a focused feature set — and then begins its own drift toward complexity. Understanding this cycle helps teams resist the pressure to add "just one more" feature and recognise when a product has outgrown its original purpose.

8. Hyrum's Law

"With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviours of your system will be depended on by somebody."

Documented behaviour is not the only behaviour that matters. If your API returns results in a consistent order that is technically undefined, some users will depend on that order. If a bug exists long enough, someone builds a workaround that depends on the buggy behaviour. This is why breaking changes are expensive and why deprecation periods need to be long. The practical advice: treat every observable side-effect as a potential contract, not just the things explicitly documented.

9. Price's Law

"In any group, half the work is done by the square root of the total number of people."

In a team of 9 engineers, roughly 3 produce half the output. In a team of 100, roughly 10 do. This does not mean the other contributors are useless — support, maintenance, and coordination work matters. But it does mean that as organisations grow, the proportion of highly productive contributors shrinks relative to the whole. Identifying and retaining those contributors — and understanding what enables them — is disproportionately important.

10. Ringelmann Effect

"Individual productivity decreases as group size increases."

First observed in 1913 by Maximilien Ringelmann in a tug-of-war experiment: individuals pulled harder alone than in groups. As group size grew, individual effort declined. Two distinct forces drive this: coordination loss (it becomes harder to synchronise effort) and motivation loss (individuals feel their contribution is less visible and less critical). Both apply directly to software teams. Large teams move slower per person, not just because of Brooks's Law communication overhead but because individual accountability dilutes.

11. Goodhart's Law

"When a measure becomes a target, it ceases to be a good measure."

Any metric can be gamed once it becomes the thing people are evaluated on. Velocity points inflate. Bug counts fall because tickets aren't opened. Test coverage rises because engineers add trivial tests against untested code. Revenue metrics improve through discounts that destroy margin. Retention metrics improve by making cancellation deliberately difficult. Goodhart's Law doesn't mean you shouldn't measure things — it means metrics need to be rotated, combined, and always examined alongside context.

12. Gilb's Law

"Anything you need to quantify can be measured in some way that is superior to not measuring it at all."

Tom Gilb's principle is the necessary counterbalance to Goodhart. Yes, imperfect metrics get gamed. But the alternative — measuring nothing — is worse. Without measurement, discussions about performance, quality, and progress become pure opinion. An imprecise metric still provides directional signal. The goal is not to find a perfect metric (it doesn't exist) but to use several imperfect ones together, stay alert to gaming, and refine the measurement approach continuously.

13. Murphy's Law

"Anything that can go wrong will go wrong."

The well-known aphorism has a precise engineering implication: any edge case that is skipped "because it's unlikely" will eventually occur in production, typically at the worst possible moment. This is not fatalism but a design principle. Systems should be built to degrade gracefully. Error paths should be tested, not just the happy path. Incidents should be assumed, not hoped away. The combination of Murphy's Law with Hofstadter's Law explains why software projects are hard: tasks take longer than expected, and the unexpected things that can go wrong do go wrong.

Conclusion

None of these are absolute laws in the physical sense. They are mental models — compressed descriptions of patterns that recur often enough to be worth naming. Understanding them doesn't make projects succeed automatically, but it reduces the number of predictable surprises. The developer who knows Brooks's Law resists the pressure to hire immediately when behind schedule. The manager who knows Goodhart's Law designs review processes that examine context, not just numbers. That kind of awareness compounds over a career.