Many people have been writing and theorising about software for many years. Slowly as time progresses certain authors and speakers have made predictions, or, statements that seem to catch the imagination of the industry. These guidelines, principles, and instructions can help teams quickly explain concepts and share ideas, many are well-known and universally agreed upon. Other laws might make less sense at first glance, while the stories behind others are a little questionable.

Once an idiom becomes popular enough they somehow seem to end up being called 'laws'. These are now the type of laws where if you break them the police are not going to come to break down your door and drag you off in chains.

In this article, we will deep-dive into some of the most popular laws and figure out if they still hold merit today. If you are looking to level up your software game, then read on as this is the tutorial for you 🔥🔥🔥

I expect that you will likely have encountered the first law that we will review, Murphy's Law:

Anything that can go wrong will go wrong

Fun fact, Murphy was Captain Edward A. Murphy of the U.S. Air Force. The saying apparently came about in 1949 while he was performing a studied the effects of rapid deceleration on pilots, so nothing to do with software.

The origin of the saying can't even be agreed upon. According to Wikipedia, Murphy was performing some type of test involving G-force and Chimpanzees. One test failed because Murphy's assistant calibrated something wrong. Murphy apparently said something like, "If that guy has any way of making a mistake, he will."

"Murphy's law" came about later on through conversations among other members of the team. His saying was condensed to "If it can happen, it will happen", and named after Murphy in mockery...

In fact, there was a dude called Augustus De Morgan who in 1866 wrote 'the term 'what-ever can happen, will happen' in a paper named 'Supplement to the Budget of Paradoxes'. So Murphys taking credit for other people's homework. My final Murphy fun fact, is that Murphy is also accredited with 15 other laws including:

  • Nothing is as easy as it looks.
  • Everything takes longer than you think.
  • If there is a possibility of several things going wrong, the one that will cause the most damage will be the one to go wrong. Corollary: If there is a worse time for something to go wrong, it will happen then.
  • If anything simply cannot go wrong, it will anyway.
  • If you perceive that there are four possible ways in which a procedure can go wrong, and circumvent these, then a fifth way, unprepared for, will promptly develop.
  • Left to themselves, things tend to go from bad to worse.
  • If everything seems to be going well, you have obviously overlooked something.

The truth is that one of the most famous sayings used in software has nothing to do with software and was never exactly said by its creator... FAIL ❌

Just because the origin of the law is nonsense, that does not mean that it is not useful. To get the most out of this law in the context of software, as you write code you should aim to keep in mind that at some point the code you are writing will likely go wrong. To prevent the worst-case scenario from occurring you should always build in fail safes. Creating things like unit tests, integration tests, Ci/Cd pipelines, use a feature flagging with kill switches are all good practices that will help protect your code when things inevitably go wrong!

Obviously, there are other of other useful laws out in the software universe. Here's another one to get you thinking known as [Wirth’s law]( https://en.wikipedia.org/wiki/Wirth):

Software is getting slower more rapidly than hardware becomes faster.

At first glance, some people might think this is just being facetious, however, what if we said things this way...

Windows 95 was an operating system created by Microsoft. It shipped with a web browser, drivers to run hardware, tools to listen and record audio and even a few games. Windows 95 was 19 MB in size and needed 50MB to run. Looking at my phone today, the voice recording app takes up 90MB alone. Windows 10 takes over 4GB. This is 133 times bigger than 95., however, it is not 133 times faster, or, does it ship with 133 times more features?

When you start thinking about this statement in relation to how software size has ballooned over the years it is interesting. Every year developers have more and more reliance on using third-party packages within our applications. Yes, these packages make us more productive and prevent us from reinventing the wheel, but under the hood, our software is also becoming more of a mystery, more at risk of things doing things we are not aware of, and finally adding lots of bloat

🤔

Wirth’s law was made by a Switz developer called Niklaus Wirth. In an article named A Plea for Lean Software, Writh points out that hardware typically will need to jump many megabytes whenever a new software release is made. This article was written in 1995 and whenever I seem to upgrade any bit of software, this law seems to be true, the size needed to install the operating system and its apps always go up, never down!

How can we use this law to make progress? When writing software, aim to remove references to any unused packages. Keep your dependencies to a minimum. Ensure that when you use packages you use lean ones. Doing this will help you to break Wriths law!

The next law is handy quote to keep in your pocket the next time a project manager comes and bothers you while you're trying to get some work down and things are running late. This saying was made by Tim Lister that was quoted in book written by Tom DeMarco called Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency. Why are the origins of these saying never simple?

People under time pressure don’t think faster

Basically, as coding is a thought-intensive exercise, it is impossible to speed up your thinking. I have seen this situation play out time and time again at pretty much every company that I have ever worked for. In the haste of trying to move quicker in a late project, the project manager adds extra admin tasks into your daily activities in the guise of getting things back on track. A project manager might run additional meetings, get additional people involved, make additional checkup calls with you, and even ask you to start giving daily progress updates.

Adding all these additional tasks definitely gives more visibility, however, the extra admin only makes things slower. First, with extra meetings comes additional context switching. I assume most viewers are very familiar with the concept of context switching and the issue surrounding it... after all, it's our go-to defence whenever we're asked to do something else rather than focus on the code we're currently writing. If you do not know about context switching, read this.

In essence, when you need to jump from task to task frequently, it has been proven time and time again that people will take longer to complete that task. Despite the project manager's best intentions, the added meetings will only make things worse. The better solution is either to go back to the project sponsor and change the deadline or, reduce the scope of what needs to be built. Trying to get the work done quicker, only results in it taking even longer. Use this quote the next time you see this issue playing out in your office!

The next law is another one that might seem like a joke at first glance, however, from my experience very true. The next law is known as the 99 Rule was made by Tom Cargill of Bell Labs:

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.

If you do the maths, this statement adds up to 180%, meaning most software development projects will run significantly over the deadline because people underestimate how long it will take to do the intricate parts of a project.

When assigning story points in sprint planning I always like to bring up the classic quote 'the devil is within the detail' when I feel like someone is underestimating story points.

Just like how the bigger part of an iceberg is floating underwater, when planning a task it is very easy to forget all the other smaller related tasks that go with it. When doing the work what is the chance you will get merge conflicts, lose time while waiting for someone to review your code, encounter dependency conflicts, or even encounter failed tests within areas of the codebase that you have not touched? When you start including the time it takes to perform these essential non-so-obvious tasks within your original estimate, time disappears and your project runs late.

My advice is to keep this adage in mind when planning and always give yourself 50% wiggle room to get something done. According to the research, humans in general tend to underestimate rather than overestimate. So be conscious to force yourself into estimating higher to become more accurate.

Everyone, including myself, is rife with saying something like, yeah it will take 10 minutes and a day later it gets delivered. One famous programmer Scott Hanselman has a podcast called Hanselminutes. Scott's co-workers came up with the term Hanselminutes as something quoted as a 10-minute task that took a lot longer.

The next law is one that I didn't fully grasp when I read it for the first time:

Any piece of software reflects the organizational structure that produced it

This law is called Conway law and the first time that I read, my initial reaction was who cares?

Its when you start to think about this i n a little more details that it becomes more useful. The full law is

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations

When you think about this statement you need to pin your thinking back to how companies are structured. Let us say that a company is structured by discipline. Let us say a company has two teams one is made up of frontend developers the other one is comprised of backend developers.

Let us say we have a problem, the way within which a problem will be solved within that company will be based on how the teams have been split. If something needs solving, a team will likely fix the problem using the skills they know, rather than potentially a more optimal way that they do not understand.

This is why how you structure a team has hidden consequences on how your software will be built. In my opinion, having multi-discipline squads that are responsible for specific areas can lead to an overall better architecture. When designing your team structure, keep in mind that your choices will also influence the end quality of your software. This is probably a very subtle point that is very easy to overlook, however, that is the way that you can defend against Conways's law.

The last quote I want to mention seems like a fitting one. The idea behind going over some of these laws is to help you become even more of a coding legend, however, as quoted by Jessica Gaston. Despite lots of research I am ujnabel to find anything about Jessica Gasto, who she is and when she said it. This could be a made up thing, where, I like it...

One man’s crappy software is another man’s full-time job

THe takeaway is that even if you ignore everything I've mentioned in this article and you end up writing crappy software, at least you'll be keeping someone employed to maintain your monstrosity 😉

There is one final law that I left out of this article, Brooks Law. If you want to learn about Fred Brooks and his law, I recommend that you check out this article next. Happy Coding 🤘