The 13 software engineering laws
Hyrum's law, Conway’s law, Zawinski's law, and 10 others.
Some of those are famous, and some are quite niche. ALL of them are super useful to engineers and managers.
Curious to know how many were new to you:
Parkinson’s law
Hofstadter’s law
Brooks’ law
Conway’s law (and the Inverse Conway's law)
Cunningham’s law
Sturgeon’s law
Zawinski’s law
Hyrum’s law
Price’s law
The Ringelmann effect
Goodhart’s law
Gilb’s law
Murphy’s law
For each, I’ll share:
The law
A relevant comic (if I found one)
Why does it matter to engineering managers
Let’s go.
1. Parkinson’s law
Work expands to fill the available time.
This is a famous one, that is used to justify fake (and sometimes unreasonable) deadlines.
Why it matters
We covered it in depth in
’s great guest post. By setting deadlines, you will probably get better results. It's all about playing with the Iron Triangle of scope, resources, and time.Like any law, this one can be abused. Hofstadter’s law is a great counterbalance:
2. Hofstadter’s Law
It always takes longer than you expect, even when you take into account Hofstadter’s Law.
Software projects are almost always late, even when you factor in buffer time. So if you use Parkinson’s law to justify short deadlines, you’ll either:
Completely burn out your team
Always be late
Why it matters
Those two laws cover everything you need to know about why estimation in software is so hard. Take endless buffers - you’ll waste time on meaningless work. Too short buffers - you’ll be late.
No quick way around it - just tons of practice and communication :) (and having a negotiable scope)
3. Brooks’ law
Adding manpower to a late software project makes it later.
The famous saying is “9 women can’t make a baby in a month.”
Every EM under pressure knows this feeling, when a higher-up says: “This is super urgent, you can get any people you need from other teams”. Right… Or just stop bothering me and let us work 🙃
Why it matters
You cannot be an engineering manager without being a part of a late project (see the 2 laws above).
Most EMs don’t fully grasp this law. They think the reality is more similar to the Ringelmann Effect (which we’ll cover in a sec). So let’s say you have 4 people on a late project, and you are offered 2 more senior engineers. You know that it won’t add 50% productivity, but you think you will for sure go at least a 5-10% faster.
Too often, the reality is you will go SLOWER!
(Depending of course on many variables. Like every law here, it has its limits).
4. Conway’s law
Organizations produce designs which are copies of the communication structures of these organizations.
For example, A SaaS company has separate frontend and backend teams. Because these teams operate separately, their communication structure affects the product architecture:
The frontend team builds a UI that expects data in a certain format.
The backend team builds APIs based on their own assumptions.
The API responses don’t match exactly what the frontend expects, requiring extra transformations.
Over time, the SaaS app ends up with extra layers of glue code and inefficiencies because the teams didn’t collaborate closely.
Why it matters
You can Inverse Conway’s law to your advantage.
A great example is what Flo did: they struggled with 3-week app store release cycles for their mobile app. So they put in each team just one iOS and one Android engineer, and 2-4 backend engineers. By pushing more functionality to the backend, they can release 20-30 times per day instead of every few weeks.
5. Cunningham’s law
The best way to get the right answer on the internet is not to ask a question, but to post the wrong answer.
People love correcting others:
Why it matters
In 6 secrets for never being blocked again we covered how can you use this to unstuck yourself:
Instead of submitting a request to the DevOps team, waiting for them to prioritize it, and eventually getting it done, simply open a Pull-Request to do it yourself. Even if you have no idea what you are doing. Look at the merged PRs, find a similar one, and try your best.
This does a number of things:
The DevOps team will see your PR and say “wtf is this?”
They’ll reply quickly on the PR with what needs to be fixed
You’ll have better knowledge of what to do next time
The DevOps team will gradually standardize this process with automation and policies
6. Sturgeon’s Law
90% of everything is crap.
Like the 80/20 Pareto, but on steroids. Whether it's code, ideas, or features, most things suck.
Why it matters
Most of the features you release will be useless, and a small percentage will be the core product of your company. When people talk about the 10x (or 100x) engineer, it’s not engineers who create 10x more code - but those who create 10x more value for the company.
If we just accept the roadmap our PM ‘hands’ to us, we risk working on the 90% crap, with features that don’t move the company anywhere.
‘Just building what I’m told’ is especially dangerous because of the next law:
7. Zawinski’s Law
Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones that can.
This is especially true in the AI-era! It’s so easy now to add chatbots (or any feature) everywhere, making your product a gigantic monster. Maybe it’s ok that your customers will still have some spreadsheets outside of your product…
Why it matters
That’s how feature creep happens - continuing to add features to the point that they undermine the product's value. Users complain that the product is becoming too complicated or confusing or can't find the functionality they need. In particular, the fresh ones are completely lost!
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 behaviors of your system will be depended on by somebody.
This one is truly hilarious:
Why it matters
The law talks about APIs, but I believe it’s relevant to features too. As we saw in Sturgeon’s Law, 90% of everything is crap.
BUT, you’ll still spend tons of time maintaining 100% of your features - because as soon as you release something, there will be at least one customer who will use it. When you try to remove it, they’ll of course complain… And some business stakeholders will pressure you to keep supporting that feature.
I’ve discussed this problem in Feature flags are ruining your codebase. Feature flags are a great tool, but they can be ‘abused’ to give PMs an excuse to not make hard decisions, such as completely removing a feature from the codebase.
9. Price's law
In any group, 50% of the work is done by the square root number of people.
For example:
If you have 10 engineers, half the output can be attributed to 3 of them.
Out of 100 engineers, 10 will generate an output similar to that of the other 90.
I learned about this law from
’s LinkedIn post, where he used it to explain why Twitter didn’t collapse:Elon Musk fired 50% of Twitter in November 2022.
Price's square root law explains why Twitter didn't collapse, even when a further 30% were fired.The square root of the original 8,000 employees is just 90!
Why it matters
Scaling teams is hard. If you want to X2 your output, Price’s law means you’ll need to hire 4X more people. One explanation for that law is the Ringelmann effect:
10. Ringelmann effect
The tendency for individual members of a group to become increasingly less productive as the size of their group increases.
I was shocked to learn this phenomenon was discovered and analyzed more than 100 ago (in 1913!), with a rope-pulling competition. The more people participated in each group, the less effort each member gave:
Ringelmann identified 2 reasons:
Loss of motivation (social loafing).
Coordination problems.
Why it matters
Yes, it’s not only about physical force.
wrote about The magic of small engineering teams (they have 47 people organized in 15 teams).Especially in smaller startups, with ‘new’ products, don’t be afraid to break out into smaller teams and clear areas of ownership.
11. Goodhart’s law
When a measure becomes a target, it ceases to be a good measure.
This one is pretty famous. It gets thrown around constantly in tech, saying that you shouldn’t measure lines of code or PRs, as people will (rightfully) game it.
Why it matters
Every KPI your team or company uses can be gamed.
Revenue? → Huge discounts
Churn? → Make cancellation super difficult
New users? → Aggressive ad campaigns that bring low-quality lead
Support ticket resolution time? → Closing tickets quickly without really solving the problems (I’ve experienced that as a customer…)
It’s the same with velocity, actual VS planned, and so on - any metric by itself can become useless quite fast.
Still, the answer is not “We shouldn’t measure”. If we take that approach, we will fall into Gilb’s trap:
12. Gilb’s law
Anything you need to quantify can be measured in some way that is superior to not measuring it at all.
Basically saying that it might be hard to measure, and the measurements might not be 100% accurate, but any measurement is better than nothing.
Why it matters
This is a great counterbalance to Goodhart’s law. Instead of ‘giving’ up on measuring, we should start with something and work to improve it.
We’ve seen it happening with developer productivity. DORA, SpaceX, DevEx - different ways, each providing different advantages.
I love the recently released DX Core 4 which makes a lot of sense to me.
13. Murphy’s Law
Anything that can go wrong will go wrong.
No list of laws is complete without Murphy :)
Why it matters
We like to laugh about it, but I’m sure you have experienced something like this:
You are under pressure to release a feature. There is just this one edge case, that is super complex to test, and you are sure it will never happen. So you decide to cut a corner.
Guess what breaks production the next Sunday?
After it happened to me 4-5 times (yeah, I know…), I’m now trained to catch those thoughts. Every time I think something is improbable, I go the extra step to verify that we are still covered.
Final words
None of those laws is a ‘real law’ - they are just great mental models. I hope that having them in mind will save you some pain in the day-to-day.
Check out this repo for some additional laws and principles!
And if you are an Engineering Manager, you are welcome to join my free 30-minute session about how the top 1% of EMs drive business impact on April 16th. I would love to see you there!
Murphy's Law was originally a design principle: design it so it can't go wrong.
Instead of telling people that they have to put the red wire on the red socket, and the black one on the black, make the red one square and the black one round, so they don't fit.
More of this is needed.
Finally all these laws in a single list!