5 Laws Every Software Developer Should Know

Understanding these laws can be the key to success.

Shubham Pathania
Dec 16, 2020 · 4 min read
Image for post
Image for post
Photo by Ambreen Hasan on Unsplash

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

Kernighan’s Law is named for Brian Kernighan and derived from a quote from Kernighan and Plauger’s book The Elements of Programming Style. It states —

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.

Final thoughts

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.

The Startup

Medium's largest active publication, followed by +756K people. Follow to join our community.

Shubham Pathania

Written by

A coder by Day || Writer by Night || A great writer lies somewhere between fiction and reality.

The Startup

Medium's largest active publication, followed by +756K people. Follow to join our community.

Shubham Pathania

Written by

A coder by Day || Writer by Night || A great writer lies somewhere between fiction and reality.

The Startup

Medium's largest active publication, followed by +756K people. Follow to join our community.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store