This is always a difficult part of software development to pin down, and it's certainly not anything they taught in school when I was there. You might as well ask a team of a dozen writers to write a novel. Yeah -- think of the odd looks you'd get -- but it's true, a piece of software is a lot like a novel, with characters, plots, background, themes, and so forth.

As you've pointed out, managers seem to think software projects are just like plowing a field -- more people means the job gets done faster. But writing software is not like that at all -- it's creative work, and certain architecture rules need to be followed.

Rather than an inverse curve, the people/throughput curve is probably U-shaped, with a sweet spot at 6-12 developers. Any more than that, and a project should be split into sub-projects. Formal meetings should be held only when absolutely necessary, and ideally they'd be stand up affairs. No speeches. Discuss, deliberate, decide, then move on. To quote Boone Pickens, ".. Don't fall victim to what I call the ready-aim-aim-aim-aim syndrome. You must be willing to fire."

I believe the key to success in a software development project is communication -- with good communication, the project moves forward on the right track, with development and testing working in paralell. Without it, there are endless meetings, long memos, stagnant development, and eventually, angry customers. The best developers in the world cannot overcome poor communications.