This post is part of a series of posts with my personal notes about the chapters in the book “The mythical man-month” by Frederick P. Brooks. I write these posts as I read through the book, and take notes on the concepts I find more relevant. I do, however, advise reading the book to get the full benefit out of it.
This chapter is about the impact that easiness of use and project scale, impact on the system design and the teams’ organisation.
System design
The purpose of a programming system is to make a computer easy to use.
But how do we achieve easiness of use?
A balanced function set, for easiness of use
The system needs to have a good/balanced ratio of “number of functions” Vs “simplicity of functions”. For example, think of two systems with the same set of functionality but different design:
- A system with 100 simple functions:
To perform functionality A, we need to call 30 small functions in a specific order and with several conditions; - A system with 5 complex functions:
To perform functionality A, we need to call 1 function but we need to provide a lot of arguments specifying the exact behaviour we need.
Which one is easier to use? It’s a difficult choice because they are probably both quite difficult to use!! The best option then is to find the sweet spot for the project at hand, which could be something like having 20 functions of average complexity.
Conceptual integrity, for easiness of use
Another key for easiness of use is to have functions that are predictable because they work in the same way, both syntactically and semantically. This is called conceptual integrity.
Think of the PHP set of functions that lack conceptual consistency, in the function naming but also in the type and order of the arguments. Another example I can think of is the Amazon AWS user interface, which provides a set of functions that, although may be simple to use, are in such quantity and need to be set up in such a specific way that they make the UI difficult to use.
Aristocracy and Democracy
Conceptual integrity, in turn, dictates that the design must proceed from one mind, or from a very small number of agreeing minds.
However, the bigger the product, the more minds are involved in creating it. Ho do can we scale and still maintain conceptual integrity? There ate two ways to go about it:
- The most conservative approach is to separate the labour between architecture and implementation;
- Another way is to use surgical teams as discussed before, although, in my experience, on its own, that is not a scalable solution for maintaining conceptual integrity.
Architecture tells what happens, where implementation tells how it is made to happen. So, are the architects some kind of aristocracy? No, they are not.
The architects should be restricted to a minimum amount of people because it is not reasonable to expect to maintain conceptual consistency if many people are making conceptual decisions but, aside from that, architecture work is not more important than implementation work, it’s simply different work.
What Frederick P. Brooks advocated for back in 1974, with examples of his own experience, was that architecture is an expertise different than implementation and since it is what defines conceptual integrity and consistency, it needs to be done by a few heads working together to create global design and requirements for the implementors.
In effect, a widespread horizontal division of labor [150 developers doing architecture and implementation] has been sharply reduced by a vertical division of labor [10 architects doing coarse grained design, plus 150 developers doing fine grained design and implementation], and the result is radically simplified communications and improved conceptual integrity.
The mythical man-month pg. 50
My take on this chapter
Nowadays, we know the anti-pattern of “The ivory tower architect”, the architect that just designs a system but never builds it and therefore becomes detached from the implementations difficulties and awkwardnesses. So the idea of an architects team that just works on the architecture has fallen in disuse.
Nevertheless, I still see the core idea of a specialized group of people defining the strategy as a very valid approach, and I directly relate it to the Spotify Engineering Culture (part 1 & part 2). At the company where I currently work (Werkspot) for example, we also have guilds (ie. backend guild, frontend guild, data engineering guild, UX guild, …) which meet periodically with at least one member from each team to discuss the strategy, make decisions and spread the knowledge to their teams.
@hgraca 