Why You Shouldn't Hire More Developers

TRUE.

Hiring more devs won't solve the complexity problem unless you happen to lasso a few certain devs with the right experience, perspective and willingness that can identify the true core of a problem and solve it fully and with expedience. Sadly many ("smart", "rock star") devs I've seen are content with shortcut, local maxima solutions that only buy a little bit of time before the team starts hurting again. I don't know why this is. Maybe b/c it's more fun (or feels safer) to code and produce behavior than to do the vigilant things required to stave off complexity. But this is a suicide run -- you feel the wind in your hair b/c you're hacking, coding, etc. but you're actually just running back and forth exhausting yourself and not pushing the line forward as fast as you hope. Don't let this evoke The Tortoise and the Hare fable. The team that does development right will be less like a tortoise and more like an elephant. Ground speed somewhere in between the tortoise and the hare, wise, and pushing the line at the greatest speed.

"adding manpower to a late software project makes it later."

http://en.wikipedia.org/wiki/The_Mythical_Man-Month

These debates are "evergreen" in the sense they will happen forever on tech sites. That is because they address an issue that is fundamental to the creation of software. There are 2 sides:

1.) most people can not work 60 hour weeks forever without eventually burning out

2.) "From a business point of view, long hours by programmers are a key to profitability"

This #2 is a quote from Phillip Greenspun, and I'll quote the whole paragraph because it is good:

"From a business point of view, long hours by programmers are a key to profitability. Suppose that a programmer needs to spend 25 hours per week keeping current with new technology, getting coordinated with other programmers, contributing to documentation and thought leadership pieces, and comprehending the structures of the systems being extended. Under this assumption, a programmer who works 55 hours per week will produce twice as much code as one who works 40 hours per week. In The Mythical Man-Month, the only great book ever written on software engineering, Fred Brooks concludes that no software product should be designed by more than two people. He argues that a program designed by more than two people might be more complete but it will never be easy to understand because it will not be as consistent as something designed by fewer people. This means that if you want to follow the best practices of the industry in terms of design and architecture, the only way to improve speed to market is to have the same people working longer hours. Finally there is the common sense notion that the smaller the team the less management overhead. A product is going to get out the door much faster if it is built by 4 people working 70-hour weeks (180 productive programmer-hours per week, after subtracting for 25 hours of coordination and structure comprehension time) than if by 12 people working 40-hour weeks (the same net of 180 hours per week). The 12-person team will inevitably require additional managers and all-day meetings to stay coordinated."

http://philip.greenspun.com/ancient-history/managing-softwar...

This issue won't go away and there is no easy way to resolve it. You have a human need (avoid burnout) and a business need (move quickly) and in the world of software they tend to be opposites. The upshot of the real life stresses of businesses tends to amount to: have as few programmers as possible without inducing burnout. But management can not know how many programmers that is since it is difficult to know how much work a given developer can handle without burnout. (On a personal note, I have had good years and bad years, years when the work fascinated me and years when it did not, years when working 40 hours a week was a struggle and years when 60 hours a week was fun -- and never have I had a manager who understood my motivations so deeply that they could figure out which kind of year I was headed for.)

More so, we can not expect any general improvement in the quality of management. Phillip Greenspun makes the argument here, that there has been little to no improvement in the management of software projects over the last several decades (as he says, what improvements there have been have come from new tools, such as SQL (or in modern times, git)):

http://blogs.law.harvard.edu/philg/2005/11/10/can-we-fix-the...