Microservices, Agile, Coupling & The Mythical Man Month
21 Aug 2021
I'm going to connect a few apparently disparate things together which are all related to the problem of how to manage the complexity of software.
- Microservices: Splitting a large application into highly decoupled separate services (generally) with their own data stores
- Agile: A way of building software using small autonomous teams
- Coupling: Two elements of a software system are coupled to the extent that changes made to the functioning of one are likely to require changes in the other.
- The Mythical Man Month: A seminal work on managing software teams whose major thesis is that adding more people to a team especially at the end of a project can paradoxically slow it down.
All these are connected to a principle I haven't been able to find a name for elsewhere so I'll call it the n2 rule. It's to do with the mathematical rule that the number of connections between n points is n(n-1)/2.
What it means is that the work needed to build a system with n features is proportional to n2. In terms of the complexity of the system itself and its lines of code, because if you don't think about it too much, every time you add a feature, you have to update most of the other features to make it work.
This also applies to in terms of diminishing returns in terms of adding engineers to a project, as the overheads of communication, management, cognitive load and version control all increase with n2 (n being the number of engineers).
Software engineering management has widely accepted that following agile practises is highly effective. However agile teams are designed to be fairly small, once they get over around 15 or 20 they start not to work well, so to maintain this approach with larger projects requires creating a number of smaller teams which coordinate. How though do you avoid a massive amount of communication and coordination between these teams that eats up their ability to get anything done? This is another aspect of the n2 rule.
Microservices are enjoying great popularity as an approach to building large projects because they allow the division of the larger engineering project into small services to match the division of the engineers into small teams.