3 ms·

Sigh...yes, I am familiar with the concept. That's why I said that if enough people are on the project, the length of time to completion should be the length o

Sigh...yes, I am familiar with the concept. That's why I said that if enough people are on the project, the length of time to completion should be the length of the critical path. If I were committing the fallacy you're accusing me of, I would instead believe that the project would keep getting faster as more people work on it. When instead I actually want to be able to identify where diminishing returns really kick in and a marginal person doesn't produce a baby any faster. I don't really understand the point of your comment. That projects never go faster when more people work on them? That estimating project length is useless? Being able to figure out "we can do it in a year with three people, or six months with five people, and six months is as fast as it can get done" is, in practice, useful.

philomath_mn 4y ago
I think there is a difference between > length of the critical path and > six months is as fast as it can get done unless "length of the critical path" accounts for the quadratic(ish) increase in communication overhead as you add more people. I think that is a little unclear from the question: is the length of the critical path the sum of times one person would take to do those tasks or the sum of the times an overhead-laden person would take to do those tasks?
- deleted 4y ago
  [deleted]
beardyw 4y ago
> I actually want to be able to identify where diminishing returns really kick in That is your problem. If you listen, what you are hearing is that life is not so simple. People are people, they have a mix of skills, some more, some less, some communicate well. Bigger projects suffer communication problems in different ways. What you could be hearing is the voice of experience. It comes from being bitten too many times, mostly by people who believe in such charts.
gregjor 4y ago
I agree that would be useful. So would accurately estimating the duration of a software project. And so would identifying the critical path, knowing what each team member can accomplish, and knowing the inevitable obstacles and unknown unknowns up front. If anyone knew how to reliably estimate software projects, identify the critical path, and deliver on time they would get rich for solving a previously intractable problem. In 40 years in the business I have never seen this work, no matter how talented the team and project manager. I'm not saying it can't work, just that I have not seen it happen and I am not aware of any technique. In any software project the individual personalities and team dynamics drive the project and set the pace. How do you express that on a Gantt chart? Unexpected things come up because no one can plan a non-trivial project with complete and consistent requirements. The only approach I know that mostly works is incremental development. Set shorter targets and deliverables specified well enough that the team can give realistic estimates. Do that (call it a sprint if you want), regroup, adjust velocity based on what you learn. Software projects often have what looks like a fast pace and lots of progress early on, then bog down so that the team spends 90% of the actual time on the last 10% of the schedule. Incremental development (I won't call it agile because that means almost nothing anymore) at least gives you forward progress and an increasing (rather than decreasing) ability to estimate time to finish. Good luck.

philomath_mn 4y ago

I think there is a difference between > length of the critical path and > six months is as fast as it can get done unless "length of the critical path" accounts for the quadratic(ish) increase in communication overhead as you add more people. I think that is a little unclear from the question: is the length of the critical path the sum of times one person would take to do those tasks or the sum of the times an overhead-laden person would take to do those tasks?

deleted 4y ago
[deleted]

beardyw 4y ago

> I actually want to be able to identify where diminishing returns really kick in That is your problem. If you listen, what you are hearing is that life is not so simple. People are people, they have a mix of skills, some more, some less, some communicate well. Bigger projects suffer communication problems in different ways. What you could be hearing is the voice of experience. It comes from being bitten too many times, mostly by people who believe in such charts.

gregjor 4y ago

I agree that would be useful. So would accurately estimating the duration of a software project. And so would identifying the critical path, knowing what each team member can accomplish, and knowing the inevitable obstacles and unknown unknowns up front. If anyone knew how to reliably estimate software projects, identify the critical path, and deliver on time they would get rich for solving a previously intractable problem. In 40 years in the business I have never seen this work, no matter how talented the team and project manager. I'm not saying it can't work, just that I have not seen it happen and I am not aware of any technique. In any software project the individual personalities and team dynamics drive the project and set the pace. How do you express that on a Gantt chart? Unexpected things come up because no one can plan a non-trivial project with complete and consistent requirements. The only approach I know that mostly works is incremental development. Set shorter targets and deliverables specified well enough that the team can give realistic estimates. Do that (call it a sprint if you want), regroup, adjust velocity based on what you learn. Software projects often have what looks like a fast pace and lots of progress early on, then bog down so that the team spends 90% of the actual time on the last 10% of the schedule. Incremental development (I won't call it agile because that means almost nothing anymore) at least gives you forward progress and an increasing (rather than decreasing) ability to estimate time to finish. Good luck.