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.
MURPHY’S LAW
“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.