Organisational structure
In his 1975 book, The Mythical Man-Month, Fred Brooks claimed that adding more people to a late software project would make it even later. His reasoning behind this claim, which has now become known as Brooks’ Law, was that people in a team need to communicate with each other. As the team grows in size, so to the number of interactions will increase, leading to complexity and teams getting bogged down in communication.
Adding manpower to a late software project makes it later.
– Brooks’ Law
Brooks’ Law actually considers numerous aspects of a software project, as shown in the diagram below. However, what I would like to concentrate on in this post is the communication factor. That is: the percentage of the team that each member has to communicate with. For example a team of 10 people in which each member has to communicate with 5 other people would have a communication factor of 0.5.
If Brooks’ Law is accurate, and when all other aspects are equal, teams with a higher communication factor will suffer the greatest when an attempt is made to add more people to a late project.
Software architecture
When I first read Brooks’ Law, it did not seem to fit well with my own experience of working on a large software project. In my current company, new engineers can be brought in at a late stage in order to help meet the promised delivery date.
Thinking about this a little more though, I realised that we are able to achieve this because of our software architecture. The system is divided neatly into sub-systems (or components) using systems engineering principles, and then each sub-system is further divided into software layers based on object-oriented design principles.
The result of this is that an engineer can pick up a task and work in practical isolation from other engineers, thus making the communication factor very low.
Microservices
In 1967, Melvin Conway noticed that the structure of a software system is destined to become a reflection of the organisational structure used to create it. This has become known as Conway’s Law.
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
– Conway’s Law
What I have learned since reading about Brooks’ Law is that we would ideally like to flip Conway’s Law on its head. Rather than letting the organisational structure define the architecture, we should first define the architecture that then allows us to use the most optimal organisational structure.
One solution to this problem that I have found particularly interesting is the microservices architecture. A microservice is a small, independent unit of software that can be connected to other microservices using well defined interfaces.
Companies such as Amazon and Netflix have adopted a microservices architecture, with small, independent teams being responsible for a single microservice.
Related to this is the two-pizza rule, in which Amazon’s founder Jeff Bezos states that if you can’t feed a team with two pizzas, then that team is too big. It is important to note however that not only the team size is important, but also the independence and autonomy of the team.
Conclusion
When starting a new project there are many important factors to consider and there can often be an urgency to simply get something working. Brooks’ Law shows us however that real thought should be given to the upfront architectural design if a project is to scale well and be delivered on time.
DW.