Rearranged the shelves over the holidays, and re-read a few sections of Fred Brooks' venerable book The Mythical Man-Month.

It's an interesting read, though it is largely obvious: Adding more people on a project naturally means more administrative, communications, and coordination overhead. If, at a particular stage in the project's progression, you have more people than you have clean project partitions, they could actually hinder rather than help. 

Many developers can personally identify with this indisputable observation, recalling situations where a manager with excess human resources dumped workers onto their project, against their wishes, while it was in an unpartitionable design stage. A co-op student assigned to me in just such a situation, many years back, started informally tagging their assigned tasks "MWPs" : Make Work Projects (they were quite capable, and recognized and disliked trivial tasks). Given that I was in a critical, non-partitionable task, and all following tasks depended upon it, the best I could do with their help was to get them to do competitive research.

Such is the nature of some projects during some stages. To use the classic analogy, nine women can't produce one baby in one month. Of course it's a fairly bad analogy given that those nine women can of course produce nine babies in nine months, effectively producing a "baby a month" if you wait the minimum period, but nonetheless it is the common phrase.

The mythical man-month title refers to the fact that many project managers take a project's estimated work (e.g. 100 man-months), and then request or assign a set number of people (e.g. 10 men), dividing the effort by the workforce and considering that the delivery date (in this case 100/10, or 10 months to completion from the start). Of course that is incredibly naïve, and is a recipe for disaster from the outset, and when the project starts slipping more people get added, slowing the project even more.

Thankfully, most shops use proper project timelines now, with critical paths, dependencies, and task assignments.

A couple of Mythical Man-Month quotes that I found enjoyable:

An ancient adage warns, "Never go to sea with two chronometers; take one or three."

...

An architect's first work is apt to be spare and clean. He knows he doesn't know what he's doing, so he does it carefully and with great restraint.

As he designs the first work, frill after frill and embellishment after embellishment occur to him. These get sorted away to be used "next time." Sooner or later the first system is finished, and the architect, with firm confidence and a demonstrated mastery of that class of systems, is ready to build a second system.

The second is the most dangerous system a man ever designs. When he does his third and later ones, his prior experiences will confirm each other as to the general characteristics of such systems, and their differences will identify those parts of his experience that are particular and not generalizable.

If you don't own this book, you should at least get it to stock your bookshelf (it is a required pretend-to-have-read shelf stocker). If you already understand and believe the core message of it, it's debateable if it's really worth spending the time actually reading, though: Quite a lot of it is highly specific, unique observations about the creation of OS/360, and some of it are practices that are now considered questionable. For instance, few advocate the surgical team that the book promotes (with the book example humorously including a language lawyer and two secretaries).