The laws of software development

by Irina Scurtu

Unlike legal statutes, software development 'laws' are not binding regulations or practices. These are rather distilled insights into the intricacies of software creation. These principles serve as valuable guides, steering developers away from common pitfalls and promoting effective practices.

We can look at these ‘laws’ as popular knowledge, that captures common observations and best practices. Many software development laws apply in different areas. Some apply to project management, some apply to software architecture, some to ways of working or organizations.

Below we will cover the most common ones.

Table of Contents #

Pareto Principle (80-20 Rule) #

Statement: 80% of the effects come from 20% of the causes

Source: This principle is named after Vilfredo Pareto, an Italian economist and sociologist who observed that 80% of the land in Italy was owned by 20% of the population.

Explanation: While not specific to software development, the Pareto Principle is often applied in various contexts, including software. The stated idea is that a significant portion of results or outcomes often come from a relatively small portion of inputs or factors. In our field, it might suggest that focusing on fixing the most critical 20% of software bugs can eliminate 80% of the issues.

Conway Law #

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

Source: The source for Conway's law is an article written by Melvin Conway in 1968. It was later dubbed “Conway’s Law” by Fred Brooks in his hugely influential book The Mythical Man-Month

Explanation: The idea of this law is that consciously or not, organizations that have small distributed teams tend to develop systems that are modular and use service-based architectures. On the other hand, organizations that have large and colocated teams tend to develop monolith-like architectures. Conway's Law highlights the idea that communication and collaboration patterns within an organization have a direct impact on the architecture and design of the systems they create. It's a reminder that we should consider the organizational structure when we plan and design complex systems.

Understanding Conway's Law can be valuable for organizations looking to improve their software development processes. By aligning team structures and communication patterns with the desired system architecture, organizations can work more efficiently and produce systems that better meet their needs.

Postel's Law of Communication and Robustness #

Statement: "Be conservative in what you send, liberal in what you accept.”

Source: It was coined by Jon Postel, a computer scientist who played a key role in the development of the early internet.

Explanation: It states that when a system sends data, it should send it in a well-defined manner and adhere strictly to the specifications and standards governing the communication protocol. On the receiving end, the system should be flexible in interpreting the received data. It should accept and interpret inputs even if they deviate from the standard too. This flexibility promotes interoperability and allows systems to work together effectively, even if they have minor differences. This law promotes preventing situations where strict adherence to standards might lead to communication failures, especially in a networked environment where different systems with different implementations need to interact.

Murphy's Law of Software Development #

Statement: If anything can go wrong, it will, and often at the most inopportune moment.

Source: Everyone's heard of "Murphy's Law," right? The whole "if anything can go wrong, it will" thing. Well, it's named after an aerospace engineer named Edward Murphy Jr., who worked at Edwards Air Force Base in the 1940s. He was testing a braking system for a rocket sled when a cable snapped, sending the sled haywire and injuring the pilot. Murphy said something like "If there's any way for things to go wrong, they will." His buddy Capt. John Saintsbury shortened it to "Murphy's Law," and it's been a part of our vernacular ever since. It's a reminder that things don't always go according to plan, especially when you're dealing with complex machinery or high-stakes situations.

Explanation: This law highlights the inherent unpredictability of software development. It reminds us that even the most carefully planned and executed projects can encounter unexpected problems, and we can't prevent all of them.

Law of Demeter (Principle of Least Knowledge) #

Statement: "Each unit should have only limited knowledge about other units: only units 'closely' related to the current unit." or "Only talk to your immediate friends."

Source: The Law of Demeter, also known as the Principle of Least Knowledge, originated from the work of Ian Holland in 1987 as presented in his paper titled "On the Criteria To Be Used in Decomposing Systems into Modules." Karl Lieberherr later coined the term "Law of Demeter" in homage to the Demeter project, initiated by Lieberherr and colleagues in the 1980s, which aimed to apply the principle to achieve more modular and maintainable software designs. Ian Holland formulated the principles, while the Demeter project significantly contributed to the principle's popularization and application within the software engineering community.

Explanation:

We can split this law into 3 parts:

  1. Only talk to your immediate neighbors: An object should interact with its immediate neighbors and not with distant or unrelated objects. This means that an object should not have detailed knowledge about the inner workings or structures of other objects that are not directly related to its purpose. If we think about SRP, this makes total sense.

  2. Don't talk to strangers: When an object needs something done, it should delegate the task to its immediate friends (i.e., the objects it holds references to), rather than reaching out to objects it doesn't know about.

  3. Limit the interaction and knowledge hierarchy: An object should not expose its internal structure or the structure of objects it interacts with to the outside world. It should only reveal a minimal, well-defined interface. Focus on Encapsulation and prevent chattiness.

This law advocates that we should aim to reduce coupling between different parts of a system, making each component more independent and easier to maintain. In other words, it emphasizes the importance of minimizing dependencies and promoting modular, loosely coupled system designs in object-oriented programming.

Amdahl's Law #

Statement: The law states that the maximum speedup achievable by a parallel program is limited by the fraction of the program that cannot be parallelized, known as the sequential fraction (S). The formula for Amdahl's Law is:

Speedup = 1 / (1 - S + S/P)

where P is the number of processors used.

Source: Amdahl's Law is a principle in computer architecture and parallel computing named after computer architect Gene Amdahl. Formulated in 1967, Amdahl's Law quantifies the potential speedup of a computation when parts of the computation are parallelized.

Explanation: Amdahl's Law can be applied to a wide variety of parallel computing applications like data processing, database systems and computing in general. But, no matter where we try to apply it, mathematically speaking we will never be able to parallelize a program 100% and there will always be a limit to the speedup. This limit is given by the small things that are sequential: input/output, control flow, memory management, etc. When it comes to optimizing, we should look out for these things. Simply put, Amdahl's Law says that only certain parts of a program can run faster on multiple computers. Focus on optimizing those parts to get the most speed from your parallel system.

Gall’s Law #

Statement: "A complex system that works is invariably found to have evolved from a simple system that worked."

Source: The law was developed by American author John Gall in his 1977 book "Systemantics: How Systems Really Work and Why They Fail".

Explanation: Gall's Law highlights the importance of starting with a simple working system and gradually adding complexity as needed. This approach can help to reduce the risk of introducing bugs and making the system more difficult to understand and maintain. For example, we could start developing our systems as monoliths and slowly transition them towards complex microservices, instead of diving right into a complex microservice architecture. :)

Brooks's Law #

Statement: Adding manpower to a late software project makes it later.

Source: Fred Brooks, an American computer scientist, coined Brooks's Law in his 1975 book The Mythical Man-Month: Essays on Software Engineering.

Explanation: This law suggests that adding more people to a project that is already behind schedule is likely to further delay its completion. Communication overhead and the time required for new team members to become productive can contribute to this delay. And as the team grows, the organizational structure becomes more complex. This can lead to confusion, bureaucracy, and decision-making delays. In this case, it is harder to keep everyone on the same page, distribute work effectively and be productive because it is most likely that some work causes friction inside different teams, or between teams.

Linus's Law #

Statement: "Given enough eyeballs, all bugs are shallow"

Source: Linus's Law was coined by Eric S. Raymond in his 1997 essay "The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary". It is named after Linus Torvalds, the creator of the Linux kernel. Despite the name, the book talks about two different free software development models.

  1. 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
  2. Bazaar model - in which the code is developed over the Internet in view of the public. Here, he credits Linus Torvalds, leader of the Linux kernel project, as the inventor of this model. (hence the given law name)

Explanation: Linus's Law is closely tied to the open-source software development model, where the source code of a program is made available to the public. By allowing a broad community of developers to scrutinize and contribute to the code, the theory is that the software can benefit from a collective effort to identify and resolve problems. In other words, the more people who have access to and review the source code, the more likely it is that any flaws will be identified and addressed, so the more eyes on a given source code, the fewer errors.

I think we can also extrapolate this to something related to the usage of a particular library. The more people use it, the more likely it is to create a stable library. This is one of the reasons that as an architect, I always advise and recommend using well-established libraries and packages.

Knuth’s Optimization Principle or the Premature Optimization principle #

Statement: "Premature optimization is the root of all evil".

Source: Coined by Donald Knuth, an American computer scientist who is considered one of the fathers of computer science.

Explanation: It is often cited as a warning against premature optimization, which is the practice of optimizing code before it is necessary to do so.

The principle states that it is usually better to write straightforward, understandable code first, and then only optimize it if the performance is not good enough. This is because premature optimization can often lead to buggy code that is difficult to maintain.

I think this goes hand in hand with YAGNI, stating that we need to optimize when we really need to optimize, and not anticipate the optimizations that we will (maybe) need. In regards to this rule, but not necessarily related to optimizing code, I always advise teams to keep things simple when it comes to writing code.

Parkinson’s Law #

Statement: "Work expands so as to fill the time available for its completion" or "Work expands so as to fill the allotted time."

Source: It was formulated by Cyril Northcote Parkinson, a British historian and author, in his 1955 essay "Parkinson's Law or The Pursuit of Progress".

Explanation: Parkinson's Law is often cited as a way of explaining why projects often take longer than expected. It is also used to argue against the idea of setting unrealistic deadlines. This law says that if you give people more time to do something, they will take more time to do it. This applies to software development because when we have a lot of time to complete a task, we may procrastinate or do unnecessary work to fill the time. This can lead to delays, cost overruns, and poor quality. Crazy deadlines should be the solution to prevent this 'rule' from being applied. A way to prevent this is thorough planning, task breakdown, delegation, discussion and estimations.

Conclusion #

These are just a few of the laws we encounter in our software development world. These are some nice-to-know principles that some smart people came up with. If you have other favorite laws that I didn't cover, drop me a message and I'll add them.

software development misc