The 13 software engineering laws

[jemhouston]

https://newsletter.manager.dev/p/the-13 ... ering-laws

Manager.dev
Manager.dev
Discover more from Manager.dev
The biggest newsletter written ONLY for Engineering Managers. Practical weekly articles on building and leading a software team.
Over 19,000 subscribers
By subscribing, I agree to Substack's Terms of Use, and acknowledge its Information Collection Notice and Privacy Policy.
Already have an account? Sign in
The 13 software engineering laws
Hyrum's law, Conway’s law, Zawinski's law, and 10 others.
Anton Zaides
Apr 01, 2025

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.
Source
Why it matters

We covered it in depth in James Stanier
’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

Estimating Time
Source: xkcd
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)

Join 19,300+ Engineering Managers for weekly articles on building great engineering teams.
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.”
The Mythical Man-Month Is Not A Myth | HI, I'M CHRIS CHAN
Source

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.

Source
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:
Duty Calls
Source
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.
Step off the hamster wheel with Agile and Sturgeon's Law
Source
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…
r/ProgrammerHumor - True life cycle of software.
Source
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:
Source: xkcd.com
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 Itzy Sabo
’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 Effect
Source

Ringelmann identified 2 reasons:

Loss of motivation (social loafing).

Coordination problems.

Why it matters

Yes, it’s not only about physical force.

PostHog
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.
Goodhart's Law
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.
Source: Ideogram
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!
What I enjoyed reading this week

MCP (Model Context Protocol): Simply explained in 5 minutes by Jordan Cutler

Growth at what cost? Balancing user experience and revenue by Elena Verna

The Power of Micro-Exits: My Story Building & Selling Robin by Adam
and Ben Yoskovitz
.

Tips For Better Interactions by Stay SaaSy

Subscribe to Manager.dev
By Anton Zaides · Launched 2 years ago
The biggest newsletter written ONLY for Engineering Managers. Practical weekly articles on building and leading a software team.
By subscribing, I agree to Substack's Terms of Use, and acknowledge its Information Collection Notice and Privacy Policy.
79 Likes
∙
10 Restacks
Discussion about this post
Benedikt Kantus
1d

Finally all these laws in a single list!
Like (4)
Reply
Share
1 reply by Anton Zaides
Darren Stephens
1h

3 BROOKS. No E. After Fred Brooks, as quoted in the book The Mythical Man-Month
Like (1)
Reply
Share
1 reply by Anton Zaides
4 more comments...
The slow death of the hands-on engineering manager
And how to combat it. The story of an EM who created a ChatGPT for the internal docs in a few hours
Nov 12, 2024 • Anton Zaides
129
22
Distracting software engineers is much more harmful than you think
Why software engineers MUST have no-distractions time
Apr 30, 2024 • Anton Zaides
115
2
Improve your SQL skills X2 in 5 minutes
SQL for managers is an underrated skill
Feb 13, 2024 • Anton Zaides
154
22

Ready for more?
© 2025 Anton Zaides
Privacy ∙ Terms ∙ Collection notice
Start Writing
Get the app
Substack is the home for great culture