The laws of
software development - Part1
A collection of insights and wisdom when in need of a guide
4 min read time
1 – Brooks’ Law
Brooks’ law comes from Fred Brooks’ 1975 book “The Mythical Man-Month“. Since the seventies, we have kept falling into the same error: when a project is behind schedule we think of adding more people to help the effort. In fact, adding members to a team might slow down the progress, as they will need onboarding, it will take some time before they become productive and they will make demands on the existing staff. You will likely recover this time if the project is in an early stage, it’s very unlikely if you’re close to a deadline.
I also want to report another phrasing of this law that it’s my personal favourite: “The bearing of a child takes nine months, no matter how many women are assigned“. I like this version more because it usually puts a smile on people’s faces, it’s easy to remember and it points to another issue: there’s only so much that you can do in parallel in a software team, some tasks have dependencies and constraints; adding more people might take you to the difficult situation where team members feel the pressure of the deadline and, at the same time, some of them don’t have enough to do.
Finally, this law also connects to another consideration: units of development work are not interchangeable. We might think that doubling the team size will double the performance, but the relation between the number of team members and performance is far from linear. It works on a spreadsheet, but in real life, the performance of a team is not the sum of the individual performance. It will be more if there are good dynamics, trust, stability, but it will be less if the overload of communication grows (that’s why in Scrum the ideal team size is set between 5 and 7 people) and people are constantly moved around in the organisation like a chess piece.
2 – Conway’s Law
Conway’s law was first articulated in 1967 by computer programmer Melvin Conway and was then proved by the 2011 Harvard business school paper: Exploring the Duality between Product and Organizational Architectures: A Test of the “Mirroring” Hypothesis.
Conway’s law assumes that the structure of a system will reflect the social boundaries and conditions of the organization that created it. So if your organisational design is poor (silos, communication problems, teams are shaped to be non-effective) will actually determine the quality of the architecture of your software products.
One example of Conway’s law in action, identified back in 1999 by UX expert Nigel Bevan, is corporate website design: Companies tend to create websites with structure and content that mirror the company’s internal concerns — instead of being focussed on the users’ needs.
It’s extremely useful for companies to be are aware of this law: building good quality software is not just a technical challenge, but it requires investing on the health and efficacy of the organisational design.
Conway’s law also proved out to be bidirectional: the way you designs your software systems will influence your organisational structure. Awareness of this can help organizations establish healthy social structures as projects grow. For example, microservice architecture offers social scaling as a key benefit of its method: architect your code into modular services first and then the optimal organizational structure will follow. Simpler, tidier systems with healthy communication create simpler, tidier teams with healthier communication.
3 – Hofstadter’s Law
This law comes from the 1979 book Gödel, Escher, Bach: an Eternal Golden Braid by Douglas Hofstadter. The law states the difficulty of accurately estimating the time it will take to complete complex tasks, like those in the software domain. The recursive nature of the law is a reflection of the widely experienced difficulty of estimating complex tasks despite all best efforts, including knowing that the task is complex. That’s why in Agile software development estimations are considered a way to trigger valuable conversations and decisions, but the intrinsic uncertainty around them is always considered (continuous planning instead of sticking to the original plan).
These laws from the seventies bring with them a lot of wisdom. We personally have used them successfully as valuable guides. What are your thoughts? Did you know them? Have you experienced them in your daily work? Let us know in the comments. Also, watch out for the second part of this post, coming out soon!