4 ms·

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

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.

ctkhn 3mo ago
I wonder how much a good process of meetings, tickets or whatever sort of documents etc for handling new ideas and features would speed this up or bring it back to linear. I've been in some orgs where good organization at the level above me can make the required communication between me and other dev teams lower and let us live in "good" silos
- toast0 3mo ago
  What really seems to make a difference is how well the project and the organization are at being split into indepedent groups. 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.
  - LtdJorge 3mo ago
    It’s like distributed transactions, or cache-coherency protocols for CPUs. Edit: aaaand I hadn’t read the article
  - dwattttt 3mo ago
    I've heard that project architecture has a strong enough impact on feature completion rate that you can infer how tightly coupled vs loosely plugin based it is just from graphs of feature release.
- reinitctxoffset 3mo ago
  I think it's kind of fun now. Agents can interact with Linear. I'm still playing around with like does an issue achieve anything? What is the fastest way to get a bug from the observing session to the originating session? 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.
  - trollbridge 3mo ago
    What are you talking about? A properly prompted agent generates a project with a fast, reproducible, and isolatable build. One of the best things about agentic AI is that I spend far less time on devops and on waiting on builds.
    - reinitctxoffset 3mo ago
      There are low-insensity regimes where it's all Python or whatever, and if you're in one, great. 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.
      - trollbridge 3mo ago
        For greenfield work, we are using mostly Rust, although small utilities built with Go or Python are also acceptable provided they have a comprehensive set of unit tests, an integration test suite, well-defined specifications and acceptance criteria, and thorough documentation. Once you have that, it's much easier for the AI to work on it. (Our main motivation for doing this is that it takes far fewer tokens now to get stuff done since we have all that, to the point I can leave Qwen 3.6 running in 24/7 loops accomplishing things.) 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.
AdieuToLogic 3mo ago
> 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 Staffing exceeding the above for an individual team is more a managerial genitalia contest than anything focused on organizational success.
deleted 3mo ago
[deleted]
locallost 3mo ago
Amdahl's law says something similar, adding more processors to a problem eventually gives almost no speedup because parts of the problem cannot be parallelized and need to be done sequentially. To the people wondering the meaning of the article, it's I think this.
- CyberDildonics 3mo ago
  amdahl's law is trivial tautological nonsense and has nothing to do with the mythical man month. 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).
  - locallost 3mo ago
    Amdahl's law states diminishing returns are because some processes cannot be parallelized, thus eventually they become the bottleneck. 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.
    - CyberDildonics 3mo ago
      thus eventually they become the bottleneck 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.

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.

ctkhn 3mo ago

I wonder how much a good process of meetings, tickets or whatever sort of documents etc for handling new ideas and features would speed this up or bring it back to linear. I've been in some orgs where good organization at the level above me can make the required communication between me and other dev teams lower and let us live in "good" silos

toast0 3mo ago
What really seems to make a difference is how well the project and the organization are at being split into indepedent groups. 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.
- LtdJorge 3mo ago
  It’s like distributed transactions, or cache-coherency protocols for CPUs. Edit: aaaand I hadn’t read the article
- dwattttt 3mo ago
  I've heard that project architecture has a strong enough impact on feature completion rate that you can infer how tightly coupled vs loosely plugin based it is just from graphs of feature release.
reinitctxoffset 3mo ago
I think it's kind of fun now. Agents can interact with Linear. I'm still playing around with like does an issue achieve anything? What is the fastest way to get a bug from the observing session to the originating session? 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.
- trollbridge 3mo ago
  What are you talking about? A properly prompted agent generates a project with a fast, reproducible, and isolatable build. One of the best things about agentic AI is that I spend far less time on devops and on waiting on builds.
  - reinitctxoffset 3mo ago
    There are low-insensity regimes where it's all Python or whatever, and if you're in one, great. 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.
    - trollbridge 3mo ago
      For greenfield work, we are using mostly Rust, although small utilities built with Go or Python are also acceptable provided they have a comprehensive set of unit tests, an integration test suite, well-defined specifications and acceptance criteria, and thorough documentation. Once you have that, it's much easier for the AI to work on it. (Our main motivation for doing this is that it takes far fewer tokens now to get stuff done since we have all that, to the point I can leave Qwen 3.6 running in 24/7 loops accomplishing things.) 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.

AdieuToLogic 3mo ago

> 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 Staffing exceeding the above for an individual team is more a managerial genitalia contest than anything focused on organizational success.

deleted 3mo ago

[deleted]

locallost 3mo ago

Amdahl's law says something similar, adding more processors to a problem eventually gives almost no speedup because parts of the problem cannot be parallelized and need to be done sequentially. To the people wondering the meaning of the article, it's I think this.

CyberDildonics 3mo ago
amdahl's law is trivial tautological nonsense and has nothing to do with the mythical man month. 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).
- locallost 3mo ago
  Amdahl's law states diminishing returns are because some processes cannot be parallelized, thus eventually they become the bottleneck. 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.
  - CyberDildonics 3mo ago
    thus eventually they become the bottleneck 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.