4 ms·

Assume you have a product (x) that you are considering building. If you can get to market quickly, you can maybe grow revenues or whatever. X will take 48 pers

Assume you have a product (x) that you are considering building. If you can get to market quickly, you can maybe grow revenues or whatever. X will take 48 person-months to complete 48 person months is 48 months with 1 persons 48 person months is 24 months with 2 persons 48 person months is 12 months with 4 persons etc When time to market is critical, companies will often choose to "buy time" by paying people to cut the time requirements. The math isn't as linear as I've suggested, but most of the time, for most of the projects, you can increase velocity made good by adding people to a project.

kragen 3y ago
this seems like a plausible guess about what mensetmanusman meant but usually people refer to this as 'demand for labor' rather than 'demand for time' so i'm not sure
- mensetmanusman 3y ago
  That’s what I meant. Demand for time is how I experience the labor shortage, so it seemed more suitable :)
  - kragen 3y ago
    thanks for explaining!
yellowapple 3y ago
> 48 person months is 48 months with 1 persons 48 person months is 24 months with 2 persons 48 person months is 12 months with 4 persons etc If only it were that simple: https://en.wikipedia.org/wiki/Brooks%27s_law https://en.wikipedia.org/wiki/Brooks%27s_law Basically: between the added communication/management overhead and the training/ramp-up needed, "buying time" this way can end up costing time. If more of these MBAs calling the shots read The Mythical Man-Month we'd have a less schizophrenic economy and maybe even world peace.
- kragen 3y ago
  probably ramping up to two or four humans will save you time tho, maybe even reduce the number of person-months; the humans have complementary skills, and are better at spotting design errrors and bbugs in others' work than in their own if they can keep from fighting
  - ryan_lane 3y ago
    You should really read the book listed. It only saves time when work on a project is parallelizable, and only if the communication needs between folks is low. It's not a matter of folks fighting, it's a matter of the amount of context needed to coordinate work. Often more people on a project results in the project moving slower, not faster.
    - kragen 3y ago
      don't be an idiot, obviously i've read the book
      - ryan_lane 3y ago
        Have you? Your comments don't reflect the points the book is making; in fact, they're counter to them.
    - flygurl 3y ago
      That applies far more to going from 10 to 20 than 1 to 2.
      - ryan_lane 3y ago
        If the project isn't parallelizable, it doesn't matter if you're adding 1 or 10, it's going to slow things down. Even if the work is parallelizable, if you add 1-3 people after the project is already delayed, it may still slow the project down, especially at first, because each of those people are going to need to be brought up to speed. Depending on the complexity of the task, the experience of the people, their understanding of the project, etc, it can either help or harm the project. There's a lot of nuance around whether or not adding folks to a project will make it faster or slower, and that's what the book is emphasizing. It's not a hard and fast rule of "don't add people to a project". The parent's comment didn't have any of that nuance. Just "more people can help spot errors and help with design" and the only issue they mentioned was "if they can avoid fighting". Neither of those things are what the book describes.
icedchai 3y ago
You know you’re dealing with amateur management when they think doubling people is going to linearly halve the time of a project. This completely ignores the varying skill sets, and difficulty in decomposing some tasks. Onboarding and ramp up is also very time consuming. Productivity of existing team members will drop, temporarily, as they onboard new people. Communications overhead is also very real.
- bmelton 3y ago
  If that's the point yoi thought I was making, i encourage you to reread my comment and its parent

kragen 3y ago

this seems like a plausible guess about what mensetmanusman meant but usually people refer to this as 'demand for labor' rather than 'demand for time' so i'm not sure

mensetmanusman 3y ago
That’s what I meant. Demand for time is how I experience the labor shortage, so it seemed more suitable :)
- kragen 3y ago
  thanks for explaining!

yellowapple 3y ago

> 48 person months is 48 months with 1 persons 48 person months is 24 months with 2 persons 48 person months is 12 months with 4 persons etc If only it were that simple: https://en.wikipedia.org/wiki/Brooks%27s_law https://en.wikipedia.org/wiki/Brooks%27s_law Basically: between the added communication/management overhead and the training/ramp-up needed, "buying time" this way can end up costing time. If more of these MBAs calling the shots read The Mythical Man-Month we'd have a less schizophrenic economy and maybe even world peace.

kragen 3y ago
probably ramping up to two or four humans will save you time tho, maybe even reduce the number of person-months; the humans have complementary skills, and are better at spotting design errrors and bbugs in others' work than in their own if they can keep from fighting
- ryan_lane 3y ago
  You should really read the book listed. It only saves time when work on a project is parallelizable, and only if the communication needs between folks is low. It's not a matter of folks fighting, it's a matter of the amount of context needed to coordinate work. Often more people on a project results in the project moving slower, not faster.
  - kragen 3y ago
    don't be an idiot, obviously i've read the book
    - ryan_lane 3y ago
      Have you? Your comments don't reflect the points the book is making; in fact, they're counter to them.
  - flygurl 3y ago
    That applies far more to going from 10 to 20 than 1 to 2.
    - ryan_lane 3y ago
      If the project isn't parallelizable, it doesn't matter if you're adding 1 or 10, it's going to slow things down. Even if the work is parallelizable, if you add 1-3 people after the project is already delayed, it may still slow the project down, especially at first, because each of those people are going to need to be brought up to speed. Depending on the complexity of the task, the experience of the people, their understanding of the project, etc, it can either help or harm the project. There's a lot of nuance around whether or not adding folks to a project will make it faster or slower, and that's what the book is emphasizing. It's not a hard and fast rule of "don't add people to a project". The parent's comment didn't have any of that nuance. Just "more people can help spot errors and help with design" and the only issue they mentioned was "if they can avoid fighting". Neither of those things are what the book describes.

icedchai 3y ago

You know you’re dealing with amateur management when they think doubling people is going to linearly halve the time of a project. This completely ignores the varying skill sets, and difficulty in decomposing some tasks. Onboarding and ramp up is also very time consuming. Productivity of existing team members will drop, temporarily, as they onboard new people. Communications overhead is also very real.

bmelton 3y ago
If that's the point yoi thought I was making, i encourage you to reread my comment and its parent