Fundamental Laws of Software Development

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

The realm of software engineering, like any other discipline, contains several intriguing and well-known rules, concepts, and laws.


In talks, meetings, and chats, programmers, developers, managers, and architects often utilize these. But why do they do so? Do they really assist in framing issues in a methodical way that enables us to make decisions more quickly? Or are they only empty platitudes that signify nothing?

That’s what we’re attempting to answer today!

More often than not, we prefer to nod along, unable to admit to our conversational counterparts that we haven’t truly heard of these characters from Brooks, Moore, or Wirth. These laws are made up of regulations, precepts, or well-known quotes by influential figures in the field of development.

They all have fascinating backstories that are fascinating to read while also being intriguing, amusing, and worth knowing. I’ll be sharing my observations, interpretations, and ideas on the most well-known and often used rules in software development in this article.

“Anything that can go wrong will go wrong.”

Probably one of the most famous of all laws, mostly because it is not only applicable to software development.


First derivation: If it works, you probably didn’t write it.
Second derivation: Cursing is the only language all programmers speak fluently.
Conclusion: A computer will do what you write, not what you want.

Defensive programming, version control, doom scenario’s (for those damned zombie-server-attacks), TDD, MDD, etc. are all are good practices for defending against this law.

Brooks’ law
“Adding manpower to a late project makes it later.”

The Mythical Man Month, written by Fred Brooks in 1975, is the source of Brooks’ law. It operates on the premise that the team members and the number of months required are interchangeable. This is not true, especially when developing software (or any product development, for that matter). Why? due to the time required to inform and update individuals on the project.



Conway’s law
“Any piece of software reflects the organizational communication structure that produced it.”

This rule of software development was stated by Melvin Conway in 1967. Product design is related to Conway’s law. The influence of communication architecture on software production is an observed phenomena.

Thus, a close-knit team that works in unison develops software that has intertwined features and code.

Meanwhile, a looser, decentralized team produces more modular software.

Murphy’s law
“If something can go wrong, it will.”

This is the most well-known and universally applicable law on this list. Murphy’s law is visible in all realms of project management, software development and life in general.

Murphy’s rule emphasizes a crucial idea in software development: computers act according to instructions rather than user preferences.

Hofstadter’s law
“It always takes longer than you expect. (Even when you factor in Hofstadter’s law.)”

One of the most feared questions in software development is “How long will it take?” The explanation is given by Hofstadter’s law.

This is connected to another rule, known as Parkinson’s law, which states that work expands to take up all of the time necessary to complete it. It is very difficult to predict the completion time due to Parkinson’s law and Hofstadter’s law.





Linus’ law
“Given enough eyeballs, all bugs are shallow.”

This law was described using the famous The Cathedral and the Bazaar essay, explaining the contrast between two different free software development models:

The Cathedral model, in which source code is available with each software release, but code developed between releases is restricted to an exclusive group of software developers.
The Bazaar model, in which the code is developed over the Internet in view of the public.
The conclusion?

The more widely available the source code is for public testing, scrutiny, and experimentation, the more rapidly all forms of bugs will be discovered.

Goodhart’s law
“When a measure becomes a target, it ceases to be a good measure.”

An example of Goodhart’s law in software development is lines of code. Lines of code provide a way to measure the size of a software product. But, when used as a target, code quality drops. Lines that should need refining or cutting from the software are instead built on, creating a messy plate of spaghetti code.

Gall’s law
“A complex system that works has evolved from a simple system that worked. A complex system built from scratch won’t work.”

Gall’s law, if it holds true (which it seems to do), is a good reason to start software product development with a minimum viable product (MVP).

Zawinski’s Law
“Every program attempts to expand until it can read mail. Those programs which cannot expand are replaced by ones that can.”

Speaking of complexity, Zawinski’s law suggests that, once built, products continue to expand. They add more areas of functionality until they cannot expand any more. Instances of feature creep illustrate Zawinski’s law in software development. Bloated programs soon get dropped for more streamlined options.

Eagleson’s law
“Any code of your own that you haven’t looked at for six or more months might as well have been written by someone else.”

Many think Eagleson an optimist — suggesting that six months is a generous timeframe. Either way, Eagleson’s law highlights the need for clear, effective commenting and clear coding standards. After all, not even the original programmer could decipher messy code later down the line.

Lubarsky’s law
“There’s always one more bug.”


Finally, for all your programming best practices, updates, and maintenance, there is always one more bug to fix. Or one more thing to tweak, or add, or learn. A programmer’s work is never done, after all. So, remember, when it comes to software development, done is better than perfect!

Ninety-Ninety Rule:
“The first 90% of the code takes 10% of the time.
The remaining 10% takes the other 90% of the time!”

Knut’s optimization principle:
“Premature optimization is the root of all evil!”

If you try to optimize with future states in mind trying to account for future edge cases, you will inherently keep increasing the complexity of the solution of the system itself while not even properly knowing what the future problem state would exactly be.

Lastly, here’s a couple of more..

“We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run”
— ℝ𝕠𝕪 𝔸𝕞𝕒𝕣𝕒

“Any sufficiently advanced technology is indistinguishable from magic”
— ℂ𝕝𝕒𝕣𝕜𝕖’𝕤 𝕋𝕙𝕚𝕣𝕕 𝕃𝕒𝕨

“Institutions will try to preserve the problem to which they are the solution”
— ℂ𝕝𝕒𝕪 𝕊𝕙𝕚𝕣𝕜𝕪

“It’s a curious thing about our industry: not only do we not learn from our mistakes, but we also don’t learn from our successes”
— 𝕂𝕖𝕚𝕥𝕙 𝔹𝕣𝕒𝕚𝕥𝕙𝕨𝕒𝕚𝕥𝕖

“Increasing the efficiency with which a resource is used increases the usage of that resource”
— 𝕁𝕖𝕧𝕠𝕟’𝕤 ℙ𝕒𝕣𝕒𝕕𝕠𝕩

“If you automate a mess, you get an automated mess”
— ℝ𝕠𝕕 𝕄𝕚𝕔𝕙𝕒𝕖𝕝

“A good programmer is someone who always looks both ways before crossing a one-way street”
— 𝔻𝕠𝕦𝕘 𝕃𝕚𝕟𝕕𝕖𝕣

“Any code of your own that you haven’t looked at for six or more months might as well have been written by someone else”
— 𝔼𝕒𝕘𝕝𝕖𝕤𝕠𝕟’𝕤 𝕃𝕒𝕨

“One man’s crappy software is another man’s full-time job”
— 𝕁𝕖𝕤𝕤𝕚𝕔𝕒 𝔾𝕒𝕤𝕥𝕠𝕟

“The cheapest, fastest, and most reliable components are those that aren’t there”
— 𝔾𝕠𝕣𝕕𝕠𝕟 𝔹𝕖𝕝𝕝

“Hiring people to write code to sell is not the same as hiring people to design and build durable, usable, dependable software”
— 𝕃𝕒𝕣𝕣𝕪 ℂ𝕠𝕟𝕤𝕥𝕒𝕟𝕥𝕚𝕟𝕖

“The hardest part of design is … keeping features out”
— 𝔻𝕠𝕟𝕒𝕝𝕕 ℕ𝕠𝕣𝕞𝕒𝕟

“A software system built on top of a weak architecture will sink due to the weight of its own success”
— 𝕋𝕙𝕖 𝔸𝕣𝕔𝕙𝕚𝕞𝕖𝕕𝕖𝕒𝕟 ℙ𝕣𝕚𝕟𝕔𝕚𝕡𝕝𝕖

“Before software can be reusable it first has to be usable”
— ℝ𝕒𝕝𝕡𝕙 𝕁𝕠𝕙𝕟𝕤𝕠𝕟

“Walking on water and developing software from a specification are easy if both are frozen”
— 𝔼𝕕𝕨𝕒𝕣𝕕 𝔹𝕖𝕣𝕒𝕣𝕕

“The user will never know what they want until after the system is in production (and maybe not even then)”
— ℍ𝕦𝕞𝕡𝕙𝕣𝕖𝕪’𝕤 𝕃𝕒𝕨

“It is easier to change the specification to fit the program than vice versa”
— 𝔸𝕝𝕒𝕟 ℙ𝕖𝕣𝕝𝕚𝕤

“Increasing the number of choices will increase the decision time logarithmically”
— ℍ𝕚𝕔𝕜’𝕤 𝕃𝕒𝕨

“A man with a watch knows what time it is. A man with two watches is never sure”
— 𝕊𝕖𝕘𝕒𝕝’𝕤 𝕃𝕒𝕨

“The time from now until the completion of the project tends to become constant”
— ℍ𝕒𝕣𝕥𝕣𝕖𝕖’𝕤 𝕃𝕒𝕨

“Work expands to fill the time available for its completion”
— ℙ𝕒𝕣𝕜𝕚𝕟𝕤𝕠𝕟’𝕤 𝕃𝕒𝕨

“There’s never enough time to do it right, but there’s always enough time to do it over”
— 𝕁𝕒𝕔𝕜 𝔹𝕖𝕣𝕘𝕞𝕒𝕟

“Nothing ever gets built on schedule or within budget”
— ℂ𝕙𝕖𝕠𝕡𝕤 𝕃𝕒𝕨

“Anything that can go wrong will go wrong”
— 𝕄𝕦𝕣𝕡𝕙𝕪’𝕤 𝕃𝕒𝕨

“I have always found that plans are useless, but planning is indispensable”
— 𝔻𝕨𝕚𝕘𝕙𝕥 𝔼𝕚𝕤𝕖𝕟𝕙𝕠𝕨𝕖𝕣

The engineering management community abundantly creates and embraces these laws and principles, and rightfully so. They have their own bit of wisdom to them, that definitely helps you check yourself with the proper reasoning that one might very easily miss when coming across such scenarios.





Tags: , ,


Articles - Category