[enjo]

Except sometimes you CAN throw manpower at a problem and solve it more quickly. All projects are not the same, and all problems are not the same. It largely depends on how parallelizable the work is and how competent the overall system architecture is.

Point being: lets not turn platitudes into rules:)

[saurik]

"when in reality as we all know, efficiency drops sharply after a point" <- this is simply a rule: every possible task has some granularity past which point it cannot be decomposed, and every network of dependent tasks has a critical path that determines its minimal time expenditure.

Exactly where the "point" at which efficiency drops sharply is certainly project-dependent, but thesash didn't claim that it was not: only that people make the mistake of not realizing that this is even a problem worth understanding and taking into consideration, much less a fundamental one that will likely affect their project.

[thesash]

Exactly, 2x people != 2x productivity, it simply doesn't work that way.

[thesash]

My point isn't about throwing manpower at a problem, it's about diminishing returns. The notion that if you put two people on a problem they will be able to solve it twice as fast is a logical fallacy. That's a fact, not a platitude. That being said, if you put 100 people on the problem, you may be able to solve it quickly, but even then you will eventually reach a point where adding more people does not add any more benefit. That's what I wish more non-technical folks understood.

[enjo]

If you put two people on the exact same problem, sure. But, software systems are made up of LOTS of problems, a large amount of which can be solved in parallel.

That's why it's a platitude. It gets bantered about by developers as an explanation about why we just can't go any faster (hiring people is a lot of work after all), but in reality they CAN go faster with more people working on the various problems that make up the system.

Of course there is a point of diminishing return. The management costs come into play. The communication inefficiencies. The process issues. Those can be largely solved with good leadership, however.

It's a rule that is only true when it's true, which doesn't make it that useful to me. I've grown teams on multiple occasions from one or two developers to much larger numbers. While productivity may not have increased linearly, it sure made the projects go much faster. Hell I'd argue that doubling a two person team more than doubled productivity just because the external drags tends to be more distributed which reduces the context switching developers are having to do.

I think there are many more shades of grey that inexperienced founders just don't recognize when they're bound to that idea.