Fred Brooks and the mythical man month observed that communication between people expands faster than linear, and that adding more people to a project makes it later.
In my experience with more than a couple dozen software projects, the ideal team size to successfully deliver a non-trivial effort is between five to nine people.
One subject matter expert visionary
One technical architect visionary
One or two technical masters
One or two UI/UX masters
One or two padawans capable of becoming a master
I've been on projects where everybody needs to know everything, and on projects where many groups can be insulated from others.
The more your group can work without needing a meeting with other groups, the more things can progress in parallel.
Some projects won't work well with that constraint though. And some organizations won't either.
Edit: aaaand I hadn’t read the article
But it's secondary.
The wall is build. If you can AI program, your problem is the build is too slow, too unreliable, not secure enough from a supply chain standpoint.
That is where one competent senior hacker tops out today. The agents are yielding to a CI that gets 35% per-vCPU occupancy.
The wall right now is skill or build, depending on your skill.
When you're dealing with multiple platforms, or hardware accelerators, or mostly all of economically relevant shit in the AI era you don't get a small, clean, fast build.
Fable can't print a Tauri faux-native app without dragging in half of LLVM.
If your build is bloated and slow, it would seem prudent to go and fix that, possibly converting a codebase from some other language or build system to something that can be built and tested very quickly. Slow builds and slow unit tests are a choice.
If you're not running an elite `bazel` or `buck2` RBE with `nativelink`? You're not even playing.
Having a bloated, barely-maintainable codebase and a build that takes hours and needs 100GB of storage is not a badge of honour.
To the people wondering the meaning of the article, it's I think this.
The mythical man month is about communication between people and the amount of work to be productive in a project. It's about people colliding with programming.
It has nothing to do with a vague statement that "eventually" you have diminishing returns on processors (of course there is some limit even though different tasks could be many orders of magnitude apart).
For Brooks the communication between people starts to dominate the time spent the more people you add, so it will eventually become the bottleneck.
For me it's an interesting parallel. Feel free to come up with your own conclusions.
It's completely obvious and the "eventually" is where anything interesting happens. This comes from the early days of computers which is why something trivial became a supposed insight.
For Brooks the communication between people starts to dominate the time spent the more people you add, so it will eventually become the bottleneck.
Not just the communication between people while working in general but the communication to get someone involved in the project weighing down the people who would be making progress.
Feel free to come up with your own conclusions.
I did come up with own conclusion, the only similarity is the word bottleneck.
One is basically 1 + 1 = 2 and the other is a warning of a non obvious situation that comes from lots of experience and effort.
One is is good information from lots of experience, one is "the parts that don't use more cpus don't speed up with more cpus".
Unhelpful nonsense about running software vs battle won experience about making software.