Ask HN: Software answering “How long will this project take with N people?”

> if only one person is on the project, the total project time should be the sum of the time of all the tasks; if enough people are on the project, the time to completion should be the length of the longest sequence of dependent tasks

You should read The Mythical Man-Month. If that doesn't persuade you, lots of people use Microsoft Project to do what you describe -- generate Gantt charts that only bear a passing relationship to reality and prove incrementally less useful for estimating project completion.

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.

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?

> 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.

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.

These are all classic scheduling problems and there are many solutions for all of them. The least complicated might be to learn how to use a constraint solver and input your constraints directly into it. Often that is overkill because if you have less than 10 jobs and 10 workers computing the schedule that minimizes latency (critical path) is easy to do by hand. However, as you surely know, modelling developers as schedulable jobs doesn't work in practice.

I think the major project management tool is still Microsoft Project.

It should be able to do all of what you ask although I don't it will do what you ask in your third bullet point unless you specifically assign extra people to tasks.

However, as others have pointed out, how much a task will benefit of extra people is really something down to domain knowledge and experience and the tool is just that, a tool to help you.

If one woman can produce a baby in nine months, then nine women can produce a baby in 1 month.

This particular problem is easily solved with PERT charts [1] since making a baby is an atomic (blocking) task with time estimates ranging from 23 to 40 weeks. It can be combined with evidence-based scheduling[2] to collect historical data and then run Monte Carlo simulations.

Of course, this is only useful at the initial stage of a new greenfield project. For me, the more useful part is the dependency graph between tasks (actually mini-projects). Estimates are for managers. And even then they can be multiplied by 3 and still be wrong - i.e. it's guesstimation.

For general feature delivery work, a Shape Up[3] appetite (the amount of time we want to spend on a project, not an estimate) will work better. This is a fixed time budget - a variable scope.

--

[1] https://en.wikipedia.org/wiki/Program_evaluation_and_review_...

[2] https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...

[3] https://basecamp.com/shapeup/1.2-chapter-03

Is this satire? This has to be satire.

> making a baby is an atomic (blocking) task with time estimates ranging from 23 to 40 weeks.

Look, we need that baby by end of the fiscal year. Just get as much as you can done in 26 weeks and we'll ship that. We can plan for phase 2 once it's in production.

Yo went full Scrum. Never go full Scrum.

If our Sprints are 26 weeks long, we can split the BABY-123 Jira ticket into two, Phase 1 in this sprint, and Phase 2 in the next sprint.