5 Laws Every Software Developer Should Know
Software development is more complicated than the term defines it. In this industry, experience plays a vital role in the success of any software development. Experience taught us a lot of things that we pass on as lessons to others.
There are certain laws based on prior experiences that can help us to learn from their mistakes and avoid them in the future. Some of them relate to pure development, while others are related to system organizations. All of them should be useful for your growth as a software engineer.
In this article, I will discuss five laws I always have in the back of my mind when designing or implementing software.
Let’s take a closer look.
1. Murphy’s Law
This law was coined by Edward Murphy — an aerospace engineer — in response to a failed rocket test in the early ’50s. This law states —
“If anything can go wrong, it will.”
This law teaches us to create a defensive design for the critical parts of our application because something will eventually go wrong at some point.
When we expose the software to the end-users, they will find creative ways to input something we had not planned that breaks the system. So we need to make our software robust enough to detect and handle unexpected behavior.
This law emphasizes defensive programming. It is a form of defensive design intended to ensure the continuing function of a piece of software under unforeseen circumstances.
2. Conway’s Law
In the 60s, an engineer named Melvin Conway noticed that how organizations are structured influences the design of the systems they produce. He described his idea as —
“Organizations that design systems are constrained to produce designs that are copies of the communication structures of these organizations.”
This law translates well into the software development world and is even reflected at the code level. The way teams are organized to deliver software components will directly influence the design of each component.
For example, a collocated team of developers will produce a monolithic application with coupled components. On the other hand, multiple distributed teams will produce multiple separated (micro) services with a clearer separation of concern for each.
Neither design is good or bad, but they have both been influenced by the way the team(s) communicate. Open source projects, with multiple individuals around the globe, are often great examples of modularity and reusable libraries.
3. Kernighan’s Law
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
It makes the argument that simple code is to be preferred over complex code because debugging any issues that arise in complex code may be costly or even infeasible.
This refers to the problem majority of software developers face in everyday work. It emphasizes the importance of simple and human-readable code in the long run.
4. Knuth’s Law
This law from Donald Knuth reminds us that we should never try to optimize the code of an application too early or until it is actually necessary.
“Premature optimization is the root of all evil (or at least most of it) in programming.”
Indeed, a source code produced with simplicity and readability in mind will suffice for 99% of the performance needs and will greatly improve the maintainability of an application.
In Java or C#, Strings are immutable. We are taught to use other structures to build Strings dynamically, like a StringBuilder. But in reality, until you have profiled the application, you don’t really know how many times a String is going to be created and what is the performance impact. This is a classic example of premature optimization.
As a thumb rule, we should always measure first before starting to optimize anything.
5. Linus’s Law
This law was named in honor of Linus Torvalds in Eric S. Raymond’s book “The Cathedral and the Bazaar”. It says that the more people who can see a problem, the higher the likelihood that someone will have seen and solved the problem before or something very similar. It states —
Given enough eyeballs, all bugs are shallow.
Although it was originally used to describe the value of open-source models for projects, It can also be extended to processes — more code reviews, more static analysis, and multi-disciplined test processes will make the problems more visible and easy to identify.
Even though following every law won’t help us become the best software developer, it helps us to understand them better. Many of us directly or indirectly come across these laws in our daily work lives.
As a software developer, it is a good thing to be aware of these laws as they have lessons that help us to grow in our careers.