"If you quadruple your engineering headcount in a year, you will likely have less absolute throughput than if you doubled headcount. As an added bonus, you will burn way more cash."
This is a great point (although I hate the term "headcount"). It takes time to get engineers up to speed in any organization, and it usually cuts into the productive time of current engineers.
A mentor of mine, David Kathan, said something more colorful, "Of course, you can have a baby in a month if you use 9 women". People should read Mythical Man Month more.
Another section of MMM directly related to this article would be the chapter "ten Pounds in a Five-Pound Sack".
It talks about allocating memory to the various components of the OS. It begins with a delightfully outdated section on the cost of memory: if the OS weighs 400ko it costs the user $4800 per month when renting just for that memory!
His take-aways on allocating a limited resource (memory here but it could be $) are:
* Budget every aspect, not just the resource itself. Otherwise implementers will end up swapping to disk to respect the limit, killing performances.
* Define what must be achieved along with the budget. Otherwise things will be thrown over the fence to a neighbour.
* Perspective and overall integrity must be watched : "The project was large enough and management communication poor enough to prompt many members of the team to see themselves as contestants making brownie points, rather than as builders making programming products. Each suboptimized his piece to meet his targets; few stopped to think about the total effect on the customer. [...] Fostering a total-system, user-oriented attitude may well be the most important function of the programming manager".
I'm not sure I follow. I see the constraint of the first system as the natural fear of failure that comes from doing something new. It is an implicit constraint. The second system is less constrained in my view than the first.
The author of the essay linked seemed to be asserting that freedom from constraints will produce more wonderful solutions.
My interpretation of Brooks' observation on second systems is that they're what happens when the first system has been enough of a success to give people a relatively free hand to solve problems with it - so they try to solve all the things and wind up with an over-ambitious and unusable system, from which a pared-back third system emerges.
Read a story once where someone said at a company wide meeting with the CEO, if you continue to refer to us as "headcount" then we're going to start calling you "overhead".
This is a great point (although I hate the term "headcount"). It takes time to get engineers up to speed in any organization, and it usually cuts into the productive time of current engineers.