6 ms·

If you’ve never read Fred Brooks, I’d recommend it. The aphorism is a bit dated but rings true: you can’t add another developer and make the process go faster.

If you’ve never read Fred Brooks, I’d recommend it. The aphorism is a bit dated but rings true: you can’t add another developer and make the process go faster. It usually slows teams down. I’ve seen it time and again: startups move from their market-fit phase into an operational excellence phase on the backing of VC funding and they start hiring a ton of people. Most of those developers are highly educated, specialized people with deep technical skills and they’re often put to work making the boxes more blue or sitting in meetings with PMs for hours. Teams slow down output when you add more people. You don’t have a quota. It’s not like you’ll have fewer units to sell if you don’t add that 30k lines of code by Friday. This is knowledge work. The work is understanding problems and knowing how to develop solutions to them. You add more people and you end up adding overhead. Communication, co-ordination, operations overhead. The real bottle necks are people and releasing systems into production. Every line of code change is a liability. There’s risk tolerance to manage in order to achieve five-nines. A well-sized team that has worked together a long time can outperform a massive team any day in my experience.

jordwest 6mo ago
> they’re often put to work making the boxes more blue or sitting in meetings with PMs for hours Haha, this is exactly my experience. I'll never forget the best candidate I ever interviewed - my feedback was to absolutely hire him and put him on the most interesting and challenging problems. They put him in a marketing team tweaking upsell popups. He left after 2 months.
bdangubic 6mo ago
> The aphorism is a bit dated but rings true: you can’t add another developer and make the process go faster. It usually slows teams down. I've been doing this for 30-years and this is another political slogan of sorts. this is true in every single imaginable job - new people slow you down, until they do not and become part of the well-oiled machine that is hopefully your team. not sure why people insist on saying this, it is like saying "read this book, says that that Sun will rise tomorrow morning" > I’ve seen it time and again: startups move from their market-fit phase into an operational excellence phase on the backing of VC funding and they start hiring a ton of people. Most of those developers are highly educated, specialized people with deep technical skills and they’re often put to work making the boxes more blue or sitting in meetings with PMs for hours. Teams slow down output when you add more people. I wasn't talking about startups or developers making boxes more blue, I was talking about personal experience. The bottleneck, if you are doing amazing shit and not burning some billionaries money on some silly "startup" is always the code which is why we hire developers to write the code. Everything else is just coming up with some silly unrelated examples - of course there are people (at every job again) doing nothing or menial tasks - this isn't what I was talking about. > You don’t have a quota. It’s not like you’ll have fewer units to sell if you don’t add that 30k lines of code by Friday. I do have customers that want features that would make their lives easier and are willing to handsomely pay for it, that good enough? > This is knowledge work. The work is understanding problems and knowing how to develop solutions to them. You add more people and you end up adding overhead. Communication, co-ordination, operations overhead. This is only on super shitty teams with super shitty co-workers (especially senior ones) and super shitty managers. I feel for the careers in this industry where this is/was the case. A whole lot of people are terrible at their jobs in places like this - a whole lot of people... > A well-sized team that has worked together a long time can outperform a massive team any day in my experience. a well-sized team was at one point (well-sized team - 1) and (well-sized team - 2) and (well-sized team - 3) and in the future if it is right team will be even more amazing as well (well-sized team + 1), (well-sized team + 2)
- agentultra 6mo ago
  If you’ve heard it a number of times and refuse to consider what people are saying then maybe I can’t help you. I’m talking from personal experience of well over twenty years as both a developer, and for a while, a manager. The slow part isn’t writing code. It’s shipping it. You can have every one vibe coding until their eyes bleed and you’ve drained their will to live. The slowest part will still be testing, verifying, releasing, and maintaining the ball of technical debt that’s been accumulating. You will still have to figure out what to ship, what to fix, what to rush out and what to hold out until it’s right, etc. The more people you have to slower that goes in my experience. AI tools don’t make that part faster.
  - dpark 6mo ago
    > If you’ve heard it a number of times and refuse to consider what people are saying then maybe I can’t help you. What someone says “I’ve heard this a thousand times, but…”, it could be that the person is just stupidly obstinate but it could also mean that they have a considered opinion that it might benefit you to learn. “More people slow down projects” is an oversimplified version of the premise in The Mythical Man Month. If that simplistic viewpoint held, Google would employ a grand total of maybe a dozen engineers. What The Mythical Man Month says is that more engineers slow down a project that is already behind. i.e. You can’t fix a late project by adding more people. This does not mean that the amount of code/features/whatever a team can produce or ship is unrelated to the size of the team or the speed at which they can write code. Those are not statements made in the book.
    - agentultra 6mo ago
      Sure, I’m not writing a whole critical analysis of TMMM here and am using an aphorism to make a point. Let’s imagine we’re going to make a new operating system to compete with Linux. If we have a team of 10 developers we’re probably not going to finish that project in a month. If we’re going to add 100 developers we’re not going to finish that project in a month. If we add a thousand developers we’re still not going to finish that project in a month. But which team should ship first? And keep shipping and release fastest? My bet would be on the smaller team. The exact number of developers might vary but I know that if you go over a certain threshold it will slow down. People trying to understand management of software projects like to use analogies to factory lines or building construction to understand the systems and processes that produce software. Yet it’s not like adding more code per unit of time is adding anything to the process. Even adding more people to a factory line had diminishing returns in efficiency. There’s a sweet spot, I find. As for Google… it’s not a panacea of efficiency from what I hear. Though I don’t work there. I’ve heard stories that it takes a long time to get small changes to production. Maybe someone who does work there could step in and tell us what it’s like. As a rule though, I find that smaller teams with the right support, can ship faster and deliver higher quality results in the long run. My sample size isn’t large though. Maybe Windows is like the ultimate operating system that is fast, efficient, and of such high quality because they have so many engineers working on it.
senko 6mo ago
> If you’ve never read Fred Brooks, I’d recommend it. The aphorism is a bit dated but rings true: you can’t add another developer and make the process go faster. He didn’t say that. He said adding developers to a late project makes it slower, explained why, and even added some charts to illustrate it. The distinction matters. By your interpretation, no company should have more than a few developers, which is obviously false. You can argue team organization, but that’s not what Brooks was saying, either. On top of that, parent never said he hired 40 devs for one project at one time. He was talking in general terms, over the course of years, perhaps in multiple companies. Finally, let me invoke another aphorism: hours of planning can save you weeks of development. Right here you have the bottleneck staring you into the face. Of course it’s development. And unless you’re in a really dysfunctional environment, most of that development is coding, testing and debugging, where AI can help a lot.
- HarHarVeryFunny 6mo ago
  > He didn’t say that. Actually he did, or something very close to it. Obviously SOMETIMES you can add more developers to a project to successfully speed it up, but Brooks point was that it can easily also have the opposite effect and slow the project down. The main reason Brooks gives for this is the extra overhead you've just added to the project in terms of communications, management, etc. In fact increasing team size always makes the team less efficient - adds more overhead, and the question is whether the new person added adds enough value to offset or overcome this. Most experienced developers realize this intuitively - always faster to have the smallest team of the best people possible. Of course some projects are just so huge that a large team is unavoidable, but don't think you are going to get linear speedup by adding more people. A 20 person team will not be twice as fast as a 10 person team. This is the major point of the book, and the reason for the title "the mythical man month". The myth is that men and months can be traded off, such that a "100 man month" project that would take 10 men 10 months could therefore be accomplished in 1 month if you had a team of 100. The team of 100 may in fact take more than 10 months since you just just turned a smallish efficient team into a chaotic mess. Adding an AI "team member" is of course a bit different to adding a human team member, but maybe not that different, and the reason is basically the same - there are negatives as well as positives to adding that new member, and it will only be a net win if the positives outweigh the negatives (extra layers of specifications/guardrails, interaction, babysitting and correction - knowing when context rot has set in and time to abort and reset, etc). With AI, you are typically interactively "vibe coding", even if in responsible fashion with specifications and guardrails, so the "new guy" isn't working in parallel with you, but is rather taking up all your time, and now his/its prodigious code output needs reviewing by someone, unless you choose to omit that step.
deleted 6mo ago
[deleted]

jordwest 6mo ago

> they’re often put to work making the boxes more blue or sitting in meetings with PMs for hours Haha, this is exactly my experience. I'll never forget the best candidate I ever interviewed - my feedback was to absolutely hire him and put him on the most interesting and challenging problems. They put him in a marketing team tweaking upsell popups. He left after 2 months.

bdangubic 6mo ago

> The aphorism is a bit dated but rings true: you can’t add another developer and make the process go faster. It usually slows teams down. I've been doing this for 30-years and this is another political slogan of sorts. this is true in every single imaginable job - new people slow you down, until they do not and become part of the well-oiled machine that is hopefully your team. not sure why people insist on saying this, it is like saying "read this book, says that that Sun will rise tomorrow morning" > I’ve seen it time and again: startups move from their market-fit phase into an operational excellence phase on the backing of VC funding and they start hiring a ton of people. Most of those developers are highly educated, specialized people with deep technical skills and they’re often put to work making the boxes more blue or sitting in meetings with PMs for hours. Teams slow down output when you add more people. I wasn't talking about startups or developers making boxes more blue, I was talking about personal experience. The bottleneck, if you are doing amazing shit and not burning some billionaries money on some silly "startup" is always the code which is why we hire developers to write the code. Everything else is just coming up with some silly unrelated examples - of course there are people (at every job again) doing nothing or menial tasks - this isn't what I was talking about. > You don’t have a quota. It’s not like you’ll have fewer units to sell if you don’t add that 30k lines of code by Friday. I do have customers that want features that would make their lives easier and are willing to handsomely pay for it, that good enough? > This is knowledge work. The work is understanding problems and knowing how to develop solutions to them. You add more people and you end up adding overhead. Communication, co-ordination, operations overhead. This is only on super shitty teams with super shitty co-workers (especially senior ones) and super shitty managers. I feel for the careers in this industry where this is/was the case. A whole lot of people are terrible at their jobs in places like this - a whole lot of people... > A well-sized team that has worked together a long time can outperform a massive team any day in my experience. a well-sized team was at one point (well-sized team - 1) and (well-sized team - 2) and (well-sized team - 3) and in the future if it is right team will be even more amazing as well (well-sized team + 1), (well-sized team + 2)

agentultra 6mo ago
If you’ve heard it a number of times and refuse to consider what people are saying then maybe I can’t help you. I’m talking from personal experience of well over twenty years as both a developer, and for a while, a manager. The slow part isn’t writing code. It’s shipping it. You can have every one vibe coding until their eyes bleed and you’ve drained their will to live. The slowest part will still be testing, verifying, releasing, and maintaining the ball of technical debt that’s been accumulating. You will still have to figure out what to ship, what to fix, what to rush out and what to hold out until it’s right, etc. The more people you have to slower that goes in my experience. AI tools don’t make that part faster.
- dpark 6mo ago
  > If you’ve heard it a number of times and refuse to consider what people are saying then maybe I can’t help you. What someone says “I’ve heard this a thousand times, but…”, it could be that the person is just stupidly obstinate but it could also mean that they have a considered opinion that it might benefit you to learn. “More people slow down projects” is an oversimplified version of the premise in The Mythical Man Month. If that simplistic viewpoint held, Google would employ a grand total of maybe a dozen engineers. What The Mythical Man Month says is that more engineers slow down a project that is already behind. i.e. You can’t fix a late project by adding more people. This does not mean that the amount of code/features/whatever a team can produce or ship is unrelated to the size of the team or the speed at which they can write code. Those are not statements made in the book.
  - agentultra 6mo ago
    Sure, I’m not writing a whole critical analysis of TMMM here and am using an aphorism to make a point. Let’s imagine we’re going to make a new operating system to compete with Linux. If we have a team of 10 developers we’re probably not going to finish that project in a month. If we’re going to add 100 developers we’re not going to finish that project in a month. If we add a thousand developers we’re still not going to finish that project in a month. But which team should ship first? And keep shipping and release fastest? My bet would be on the smaller team. The exact number of developers might vary but I know that if you go over a certain threshold it will slow down. People trying to understand management of software projects like to use analogies to factory lines or building construction to understand the systems and processes that produce software. Yet it’s not like adding more code per unit of time is adding anything to the process. Even adding more people to a factory line had diminishing returns in efficiency. There’s a sweet spot, I find. As for Google… it’s not a panacea of efficiency from what I hear. Though I don’t work there. I’ve heard stories that it takes a long time to get small changes to production. Maybe someone who does work there could step in and tell us what it’s like. As a rule though, I find that smaller teams with the right support, can ship faster and deliver higher quality results in the long run. My sample size isn’t large though. Maybe Windows is like the ultimate operating system that is fast, efficient, and of such high quality because they have so many engineers working on it.

senko 6mo ago

> If you’ve never read Fred Brooks, I’d recommend it. The aphorism is a bit dated but rings true: you can’t add another developer and make the process go faster. He didn’t say that. He said adding developers to a late project makes it slower, explained why, and even added some charts to illustrate it. The distinction matters. By your interpretation, no company should have more than a few developers, which is obviously false. You can argue team organization, but that’s not what Brooks was saying, either. On top of that, parent never said he hired 40 devs for one project at one time. He was talking in general terms, over the course of years, perhaps in multiple companies. Finally, let me invoke another aphorism: hours of planning can save you weeks of development. Right here you have the bottleneck staring you into the face. Of course it’s development. And unless you’re in a really dysfunctional environment, most of that development is coding, testing and debugging, where AI can help a lot.

HarHarVeryFunny 6mo ago
> He didn’t say that. Actually he did, or something very close to it. Obviously SOMETIMES you can add more developers to a project to successfully speed it up, but Brooks point was that it can easily also have the opposite effect and slow the project down. The main reason Brooks gives for this is the extra overhead you've just added to the project in terms of communications, management, etc. In fact increasing team size always makes the team less efficient - adds more overhead, and the question is whether the new person added adds enough value to offset or overcome this. Most experienced developers realize this intuitively - always faster to have the smallest team of the best people possible. Of course some projects are just so huge that a large team is unavoidable, but don't think you are going to get linear speedup by adding more people. A 20 person team will not be twice as fast as a 10 person team. This is the major point of the book, and the reason for the title "the mythical man month". The myth is that men and months can be traded off, such that a "100 man month" project that would take 10 men 10 months could therefore be accomplished in 1 month if you had a team of 100. The team of 100 may in fact take more than 10 months since you just just turned a smallish efficient team into a chaotic mess. Adding an AI "team member" is of course a bit different to adding a human team member, but maybe not that different, and the reason is basically the same - there are negatives as well as positives to adding that new member, and it will only be a net win if the positives outweigh the negatives (extra layers of specifications/guardrails, interaction, babysitting and correction - knowing when context rot has set in and time to abort and reset, etc). With AI, you are typically interactively "vibe coding", even if in responsible fashion with specifications and guardrails, so the "new guy" isn't working in parallel with you, but is rather taking up all your time, and now his/its prodigious code output needs reviewing by someone, unless you choose to omit that step.

deleted 6mo ago

[deleted]