4 ms·
That's the pithy aphorism. Brook's actual claim is a lot more nuanced. The output of n programmers working on a single task is O(n), but each one of those prog
by mattkrause 7y ago
That's the pithy aphorism. Brook's actual claim is a lot more nuanced.
The output of n programmers working on a single task is O(n), but each one of those programmers must coordinate with O(n^2) colleagues. As more people are added, the coordination costs begin to to take over, and the project slips further and further behind. Thus, going from 2 to 4 programmers might be a great idea, while 20 to 40 or 200 to 400 may doom the project.
- mruts 7y agoThis is reason humans naturally form hierarchies. It changes the system from O(n^2) to like O(n log n).
- mattkrause 7y agoYup, and that was his solution. Small teams that don't need to coordinate much, and well-defined roles for the people on each team.
- jlokier 7y agoNice observation :-) It's potentially a bit better than O(n log n). If a hierarchy settles into a strong tree structure, it approaches O(n) connections people have to handle - one bidirectional connection between each person and their immediate superior. To put it a different way, a hierarchy has potential to scale without limit, or to put it differently again, the larger a system of people, the more they will be forced by necessity into a strict tree structure for the majority of 1:1 communications.
- delusional 7y agoExcept the people you need to interact with are very rarely the same people. It's much more advantageous to form cliques. Small highly connected groups that work on the same thing, possibly with some lose connections to other cliques. That's the model that most closely resembles towns, cities, and even tribes.
- coldtea 7y agoYes, but software project hardly ever tree-ize so neatly. Talking to your team boss is good for high level guidance, but wont do anything when what you really need is the details on the workings of X a colleague knows.