I agree with the author and ofcourse it comes with a caveat that putting more won't bring out more after a point. Knowing which is that point is where the excellence of management lies. They, like everybody else get reactive when pressure builds up and start ignoring the caveat.
I second Nimrod's assessment, and the classic book, "The Mythical Man Month" explains why. http://www.amazon.com/The-Mythical-Man-Month-Engineering-Anniversary/dp/0201835959/ref=sr_1_1?s=books&ie=UTF8&qid=1334620506&sr=1-1
"Larger project teams almost always exhibit higher development throughput, or output per unit of time."
I suggest that you reference Brooke's Law:
"Adding people to a late software project makes it later"
There are other phrases in this article that suggest the author believes engineers are a completely fungible resource. As in: If it takes one woman nine months to produce a child then nine women can do it in a month.
Yes, there are certain projects where a lot of manpower is needed. There are a whole lot of projects where a small team of good people can blow away a large team because the large team spends more and more of its time in communications and other overhead.
To follow on the quote I started with: Large teams almost never produce more function per dollar invested.
A Book For All Reasons Bernard Cole3 comments Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...