Five Laws of Software Everyone Should Know

In no particular order, here are five Laws of Software everyone should know.

The Law of Software Entropy

The Law of Software Entropy is a metaphorical corollary to the Second Law of Thermodynamics.

In a nutshell, it tells us that software rots over time. Even a stable piece of software that has few bugs will eventually deteriorate into a bug-ridden money-pit, if left alone. It could be due to security vulnerabilities found in dependencies or incompatibilities with new hardware, but entropy is an unavoidable property of software.

Conway's Law

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

-- Melvin Conway, 1968

Conway's Law is the fascinating observation that how a software organization splits out into teams is eventually mirrored in how the resulting software is structured. This has widespread implications for companies and open-source communities who need to tackle problems at scale but want to avoid duplicate work.

Cross-functional software teams are one attempt to offset Conway's Law. A cross-functional team incorporates all necessary skillsets within one team, and therefore causes loose-coupling of the resulting application or service to the rest of the platform.

Brooks's Law

Brooks's Law is Fred Brooks's famous observation that late software projects are only further delayed by adding additional developers.

There is a relationship with Conway's Law here since both laws are true from the same underlying cause: adding more people or teams to a software project always multiplies the amount of communication necessary to achieve each task. If you have n teams, n! communication paths exist. And since communication is the engine of product delivery, it is a case of "less is more."

Hofstadter's Law

Of course, another related law is Hofstadter's Law:

It always takes longer than you expect, even when you take into account Hofstadter's Law.

I can't remember where I first read or heard it, but I was given the following formula for making estimates when I was a young programmer:

• Take the amount of time you think it will take (say two weeks)
• Double it (two four weeks)
• Increase the unit of measure (four weeks months)

I believe this formula is an attempt to incorporate Hofstadter's Law into estimations.

The Law of Demeter

The Law of Demeter is concerned with classic software engineering ideas like encapsulation, loose coupling and high cohesion. It consists of three guidelines:

• Each unit [of code] should have only limited knowledge about other units: only units "closely" related to the current unit.

• Each unit should only talk to its friends; don't talk to strangers.

• Only talk to your immediate friends.

A common example of a Law-of-Demeter-violation is as follows. Suppose you are at the store checking out. Does the clerk ask for your wallet or your money? If the clerk asked for your wallet and then took the money out for you ("user.getWallet().getMoney(amount)") then it's a classic violation of the Law of Demeter.

In a nutshell, this works out to the loose guideline that you should be wary any time there is more than one dot in any statement involving an object. Notice the two dots in "user.getWallet().getMoney(amount)."

Some have proposed that the "Law" of Demeter is really only a heuristic you can use to detect a code smell, rather than being an actual "law." Nevertheless, it is commonly known as the "Law" of Demeter anyway.

And that's five of the more well-known laws of software.

Photo by Taylor Wilcox on Unsplash

Comments

[Nick]

Thanks for sharing! The Law of Demeter really hit home