5 ms·

Why are software companies still grappling with the mythical man month? You'd think by now we'd have learned our lesson. More hands /= more productivity, at le

Why are software companies still grappling with the mythical man month? You'd think by now we'd have learned our lesson. More hands /= more productivity, at least on a linear scale

tshaddox 4y ago
If you're talking about Brooks's law, that's a pretty specific observation that doesn't seem like it applies here. It's very specifically about adding workers to a project that is already behind schedule. It doesn't certainly doesn't mean anything as broad as "a company cannot do more things by increasing its employee count."
- Rooster61 4y ago
  I don't think I've ever worked on or even seen a software project that wasn't in some way considered behind schedule. Very, VERY rarely are the correct number of people hired at the beginning.
- quonn 4y ago
  But of the reasons Books gives, most apply regardless of the project being late, such as the communication overhead and the fact that splitting the project neatly is difficult.
  - tylerhou 4y ago
    Apollo is a large project with many features. I’m sure they have many teams working on relatively-self contained subcomponents.
  - kristopolous 4y ago
    Modern software projects are wildly different than OS/360. The insights from 50 years ago is fine abstractly but it has its limitations. Not only are there many more roles to fill but things like translation and QA scale pretty well. It's an adage, not a hard and fast dogma. Also it was specifically limited to when in the project people are added and often gets misremembered as some linear programming inspired exercise in optimal team configuration. The latter is obvious and useful (right size the team for the job) but IIRC, Brooks doesn't actually address it in the famed literature.
- Aeolun 4y ago
  I’m fairly certain that even without them all working on the same thing, 2.5x more employees will never be 2.5x faster.
  - ctvo 4y ago
    Did anyone claim a linear (let alone 1:1) gain? This was the relevant part of what you replied to: > It doesn't certainly doesn't mean anything as broad as "a company cannot do more things by increasing its employee count."
    - 0x457 4y ago
      There is a sweet spot for how many people should be on a team. That number depends entirely on a nature of tasks. I would even go as far as to say - in a good environment up to that sweet spot, productivity gain is linear. And yes, managers do expect close to linear productivity gain past that spot. Managers, that are a little smarter, start thinking about how spotify did squad (without actually knowing anything about it).
      - adolph 4y ago
        The term "Two pizza team" comes from Amazon and describes a team size such that it is the number of people that can be fed by two pizzas. The reality is that the term is not only a reference to team size but, rather, underscores the concept of "Accountability". https://developers.redhat.com/blog/2022/10/21/coming-terms-two-pizza-team https://developers.redhat.com/blog/2022/10/21/coming-terms-t... I think a well composed small team can have greater than linear improvement in effectiveness because of skill stretch and decreasing blindspots.
        0x457 4y ago
        Huh, didn't know there is a term for that. What I was talking about is something like this: SRE team has 1 member and productivity of 1, that person is overworked and if vacation is taken productivity goes to 0. Hire second person, after onboarding productivity goes to about 2 (i.e. linear scale). Hire third person, productivity will probably be a little under 3 because now they need to spend time to be on the same page. Vacation is still shaky because with such small team, knowledge will be 100% siloed due to outside performance expectations ("hey you worked on X last time, I'm going to assign this ticket to you" repeated many times). Eventually team grow to a point where they can handle all work load, share knowledge between each other and take vacations without fear (btw if you fear taking vacations - don't, it's not your fault if team can't handle without you). You can think of "work load + process" as a data structure. If work load is bog and process requires a lot of synchronizations (every meeting is essentially a Mutex for the entire team) - you won't get linear productivity increase, instead you will increase lock contention.
CharlieDigital 4y ago
Not all of that is dev. After a certain point, a lot of growth comes from marketing, sales, sales engineering, consulting, support, customer success, etc. I'd wager most core engineering teams in a co like Apollo are probably quite small and focused. I'd guess the cuts are coming from the ancillary teams.
- Rooster61 4y ago
  My comment was about the company as a whole, and slightly targeted more towards management. That said, you are right, dev usually has very little control over these kinds of decisions.
mattbillenstein 4y ago
Headcount is a good way to justify a valuation given an investment round - and you have to spend the money chasing growth anyway whether it makes sense or not.
ProZsolt 4y ago
The problem managers measured by how many people they manage so they incentivised to hire more people.
francisofascii 4y ago
In many cases, the primary goal is to increase revenue, and eventually profit, even if productivity decreases.
pwinnski 4y ago
Far too often people are added to existing teams, as if they didn't believe Brooks' observations about communication. Less often, but much better, are people being hired and put onto new teams, focused on new projects and products. Developers can scale horizontally, but not vertically.
Tangurena2 4y ago
Too many business schools teach classes that claim that managers don't need to know the business that they're in. They just need to know the math. Then apply what comes out of "organizational psychology/sociology" courses to the remaining staff. And when a new CxO takes over, he brings in his cronies who puffed him up at the last place (aka "the new broom sweeps clean"). This is why software companies end up with mismanagers who don't know beans about programming.
- no_wizard 4y ago
  Which business schools teach this, prominently? I have my own distaste of "MBA Culture" but one thing I would not say is that they teach people to ignore the business and not learn it. From what I've learned, is completely orthogonal to what they teach you in any regionally accredited business school what you are asserting here.
wintogreen74 4y ago
this seems more like a systems problem with a reinforcing and a balancing feedback loop: you're hiring for the future based on current demand, but there's a delay between the syncs of supplying capacity (hiring) and demand.
lxe 4y ago
There's a post-dotcom-bubble VC delusion that says that "growth" is the most important thing for an investor. Companies that can show growth, like Uber, are used as an example of "success," and "unicorn" becomes a thing that companies strive for. So, companies did anything to show growth, which means marketing and incentives to acquire users, to adjacent services, to hiring more staff. I'm sure leadership either knew that this is what needed to be done to get more funding, or they actually drank the cool aid.
spamizbad 4y ago
Large software orgs get around this by having multiple projects that are either loosely coupled or completely separate. Otherwise there’s be no point in hiring more than 10 engineers at any point. I’ve actually spent a long time working at engineering orgs that run super lean. On the upside there are never layoffs, on the downside you’re really constrained on what problems you can tackle - and that can have some major (negative) business implications. Anyway I can’t help but feel we are slowly reverting back to the aughts where people thought you could clone Google or whatever with like 5 engineers and didn’t understand why nobody took them seriously.
carrja99 4y ago
Because Elon is about to drop his next banger, New York Times Best Seller: "Twitter 2.0 or How I Stopped Worrying and Loved the Mythical Man Month"
- satvikpendem 4y ago
  But...he's doing the opposite, he laid everyone off. If anything I think that should be encouraged, I remember Whatsapp had less than a hundred employees when they were bought for billions, same as Instagram. I feel like we should encourage embracing the maximum productivity per person rather than throwing more people, since as they said, it doesn't necessarily work.
  - mardifoufs 4y ago
    Why should layoffs be encouraged though? Even if a corporation is bloated, I don't see why we should care if we aren't investors. It can even lead to cool stuff for everyone else, such as more open source tools and software that can usually be contributed by those "bloat" teams
    - satvikpendem 4y ago
      I just like efficient systems, both programming and organizational. Having bloat so to speak just annoys me. Making open source tools is not something I'd consider bloat, I'm talking more about those in the book Bullshit Jobs by David Graeber. Having fewer people also leads to people achieving more, ie one company with 1000 employees versus n companies that are 1/n the size, I'd say the smaller companies are much more likely to produce innovations that are useful for society as a whole.

Why are software companies still grappling with the mythical man month? You'd think by now we'd have learned our lesson. More hands /= more productivity, at least on a linear scale

tshaddox 4y ago

If you're talking about Brooks's law, that's a pretty specific observation that doesn't seem like it applies here. It's very specifically about adding workers to a project that is already behind schedule. It doesn't certainly doesn't mean anything as broad as "a company cannot do more things by increasing its employee count."

Rooster61 4y ago
I don't think I've ever worked on or even seen a software project that wasn't in some way considered behind schedule. Very, VERY rarely are the correct number of people hired at the beginning.
quonn 4y ago
But of the reasons Books gives, most apply regardless of the project being late, such as the communication overhead and the fact that splitting the project neatly is difficult.
- tylerhou 4y ago
  Apollo is a large project with many features. I’m sure they have many teams working on relatively-self contained subcomponents.
- kristopolous 4y ago
  Modern software projects are wildly different than OS/360. The insights from 50 years ago is fine abstractly but it has its limitations. Not only are there many more roles to fill but things like translation and QA scale pretty well. It's an adage, not a hard and fast dogma. Also it was specifically limited to when in the project people are added and often gets misremembered as some linear programming inspired exercise in optimal team configuration. The latter is obvious and useful (right size the team for the job) but IIRC, Brooks doesn't actually address it in the famed literature.
Aeolun 4y ago
I’m fairly certain that even without them all working on the same thing, 2.5x more employees will never be 2.5x faster.
- ctvo 4y ago
  Did anyone claim a linear (let alone 1:1) gain? This was the relevant part of what you replied to: > It doesn't certainly doesn't mean anything as broad as "a company cannot do more things by increasing its employee count."
  - 0x457 4y ago
    There is a sweet spot for how many people should be on a team. That number depends entirely on a nature of tasks. I would even go as far as to say - in a good environment up to that sweet spot, productivity gain is linear. And yes, managers do expect close to linear productivity gain past that spot. Managers, that are a little smarter, start thinking about how spotify did squad (without actually knowing anything about it).
    - adolph 4y ago
      The term "Two pizza team" comes from Amazon and describes a team size such that it is the number of people that can be fed by two pizzas. The reality is that the term is not only a reference to team size but, rather, underscores the concept of "Accountability". https://developers.redhat.com/blog/2022/10/21/coming-terms-two-pizza-team https://developers.redhat.com/blog/2022/10/21/coming-terms-t... I think a well composed small team can have greater than linear improvement in effectiveness because of skill stretch and decreasing blindspots.
      - 0x457 4y ago
        Huh, didn't know there is a term for that. What I was talking about is something like this: SRE team has 1 member and productivity of 1, that person is overworked and if vacation is taken productivity goes to 0. Hire second person, after onboarding productivity goes to about 2 (i.e. linear scale). Hire third person, productivity will probably be a little under 3 because now they need to spend time to be on the same page. Vacation is still shaky because with such small team, knowledge will be 100% siloed due to outside performance expectations ("hey you worked on X last time, I'm going to assign this ticket to you" repeated many times). Eventually team grow to a point where they can handle all work load, share knowledge between each other and take vacations without fear (btw if you fear taking vacations - don't, it's not your fault if team can't handle without you). You can think of "work load + process" as a data structure. If work load is bog and process requires a lot of synchronizations (every meeting is essentially a Mutex for the entire team) - you won't get linear productivity increase, instead you will increase lock contention.

CharlieDigital 4y ago

Not all of that is dev. After a certain point, a lot of growth comes from marketing, sales, sales engineering, consulting, support, customer success, etc. I'd wager most core engineering teams in a co like Apollo are probably quite small and focused. I'd guess the cuts are coming from the ancillary teams.

Rooster61 4y ago
My comment was about the company as a whole, and slightly targeted more towards management. That said, you are right, dev usually has very little control over these kinds of decisions.

mattbillenstein 4y ago

Headcount is a good way to justify a valuation given an investment round - and you have to spend the money chasing growth anyway whether it makes sense or not.

ProZsolt 4y ago

The problem managers measured by how many people they manage so they incentivised to hire more people.

francisofascii 4y ago

In many cases, the primary goal is to increase revenue, and eventually profit, even if productivity decreases.

pwinnski 4y ago

Far too often people are added to existing teams, as if they didn't believe Brooks' observations about communication. Less often, but much better, are people being hired and put onto new teams, focused on new projects and products. Developers can scale horizontally, but not vertically.

Tangurena2 4y ago

Too many business schools teach classes that claim that managers don't need to know the business that they're in. They just need to know the math. Then apply what comes out of "organizational psychology/sociology" courses to the remaining staff. And when a new CxO takes over, he brings in his cronies who puffed him up at the last place (aka "the new broom sweeps clean"). This is why software companies end up with mismanagers who don't know beans about programming.

no_wizard 4y ago
Which business schools teach this, prominently? I have my own distaste of "MBA Culture" but one thing I would not say is that they teach people to ignore the business and not learn it. From what I've learned, is completely orthogonal to what they teach you in any regionally accredited business school what you are asserting here.

wintogreen74 4y ago

this seems more like a systems problem with a reinforcing and a balancing feedback loop: you're hiring for the future based on current demand, but there's a delay between the syncs of supplying capacity (hiring) and demand.

lxe 4y ago

There's a post-dotcom-bubble VC delusion that says that "growth" is the most important thing for an investor. Companies that can show growth, like Uber, are used as an example of "success," and "unicorn" becomes a thing that companies strive for. So, companies did anything to show growth, which means marketing and incentives to acquire users, to adjacent services, to hiring more staff. I'm sure leadership either knew that this is what needed to be done to get more funding, or they actually drank the cool aid.

spamizbad 4y ago

Large software orgs get around this by having multiple projects that are either loosely coupled or completely separate. Otherwise there’s be no point in hiring more than 10 engineers at any point. I’ve actually spent a long time working at engineering orgs that run super lean. On the upside there are never layoffs, on the downside you’re really constrained on what problems you can tackle - and that can have some major (negative) business implications. Anyway I can’t help but feel we are slowly reverting back to the aughts where people thought you could clone Google or whatever with like 5 engineers and didn’t understand why nobody took them seriously.

carrja99 4y ago

Because Elon is about to drop his next banger, New York Times Best Seller: "Twitter 2.0 or How I Stopped Worrying and Loved the Mythical Man Month"

satvikpendem 4y ago
But...he's doing the opposite, he laid everyone off. If anything I think that should be encouraged, I remember Whatsapp had less than a hundred employees when they were bought for billions, same as Instagram. I feel like we should encourage embracing the maximum productivity per person rather than throwing more people, since as they said, it doesn't necessarily work.
- mardifoufs 4y ago
  Why should layoffs be encouraged though? Even if a corporation is bloated, I don't see why we should care if we aren't investors. It can even lead to cool stuff for everyone else, such as more open source tools and software that can usually be contributed by those "bloat" teams
  - satvikpendem 4y ago
    I just like efficient systems, both programming and organizational. Having bloat so to speak just annoys me. Making open source tools is not something I'd consider bloat, I'm talking more about those in the book Bullshit Jobs by David Graeber. Having fewer people also leads to people achieving more, ie one company with 1000 employees versus n companies that are 1/n the size, I'd say the smaller companies are much more likely to produce innovations that are useful for society as a whole.