13 Essential Software Development Laws Every Engineer Should Know

Like many fields, software development has its own intriguing laws that programmers, tech managers, and architects frequently cite in meetings and chats. Beginners often nod along without truly understanding figures like Brook, Moore, or Conway.

The following are some of the most notable and commonly referenced laws, each accompanied by its background story.

Murphy’s Law

Probably the most famous law, applicable beyond software development.

If something can go wrong, it will.

First implication: the effective code you need may never be written.

Second implication: curses are the only language all programmers can fluently speak.

Conclusion: computers do exactly what the code says, not what you intended.

Defensive programming, version control, disaster‑scenario planning, TDD, MDD, and similar practices are defensive measures against this law.

Brook’s Law

Most developers have experienced Brook’s Law, which states:

Adding manpower to a late software project makes it later.

Simply increasing staff on a delayed project can lead to disastrous outcomes; reviewing efficiency, development methods, and architecture usually yields better results. If not, Hofstadter’s Law may also be at play.

Hofstadter’s Law

Proposed by Douglas Hofstadter, this law says:

Even when you consider Hofstadter’s Law, projects take longer than expected.

It highlights the difficulty of accurately estimating the time needed for complex tasks, emphasizing the need for buffers in project planning.

Conway’s Law

Software structure mirrors the communication structure of the organization that designs it.

In other words, the system’s architecture is constrained by the organization’s communication patterns.

Many organizations are divided by functional skills, forming front‑end, back‑end, and database teams, making cross‑team changes difficult. Modern teams are increasingly organized around bounded contexts and micro‑service boundaries, aligning team structure with target software architecture.

Postel’s Law (Robustness Principle)

Be conservative in what you send, be liberal in what you accept.

Originally a principle for building robust TCP implementations, it also applies to HTML and other protocols.

Pareto Principle (80/20 Rule)

Roughly 80% of effects come from 20% of causes.

About 80% of bugs stem from 20% of the code, and similarly, a small fraction of employees often produce the majority of work.

The Peter Principle

A discouraging law for many who have experienced it.

In a hierarchy, each employee tends to rise to their level of incompetence.

Examples appear in the Dilbert comic series.

Kerckhoffs’s Principle

A cryptographic system should be secure even if everything about it, except the key, is public.

This is a core principle of public‑key cryptography.

Linus’s Law

Named after Linus Torvalds, it states:

Given enough eyes, all bugs are shallow.

The “cathedral” model restricts code development to a closed group, while the “bazaar” model encourages open, internet‑wide collaboration, leading to faster bug discovery.

Moore’s Law

Computing power per unit cost doubles roughly every 24 months.

Commonly expressed as the number of transistors on an integrated circuit doubling about every 18 months, or processor speed doubling every two years.

Wirth’s Law

Software gets slower faster than hardware gets faster.

It serves as a reminder of Moore’s Law’s impact.

Ninety‑Ninety Rule

The first 90% of the code takes 10% of the time, and the remaining 10% takes the other 90%.

Is anyone disagreeing?

Knuth’s Optimization Principle

Premature optimization is the root of all evil.

Write code first, identify bottlenecks, then optimize.

Norvig’s Law

No technology with over 50% penetration will double again, regardless of the time frame.

“Real‑Flavor” Law

Stop updating, I can’t keep up… but it’s actually great.

All programmers can relate to this law.