I’m just going to keep repeating this story until it becomes common knowledge. Apparently the need still exists! (Aperture is far from the only recent example.)
In 1996, a company called BigBook tried to make what we now know as Google Maps/Yahoo Local — an online, map-based business directory. (BigBook was across the street from, and supported by, Organic, where I worked at the time. The engineering teams comingled quite a bit, and I believe I heard this story from two of their coders; though if anyone with direct knowledge wants to confirm or deny the story in the comments, go for it.) They did a great job in a really short period of time, apparently turned down an acquisition offer from Yahoo in order to go for bigger bucks, stumbled along the way, and eventually sold to one of the legacy Yellow Pages companies.
Many of the engineers were smart folks from Sun. During the run-up to their launch, the schedule slipped significantly, and the CEO (overall a great guy) made the classic engineering management mistake of adding many more developers to the late project in hopes of speeding its completion. The engineers, of course, knew the definitive text about this mistake: Frederick Brooks’ The Mythical Man-Month, which argues:
When a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule. The bearing of a child takes nine months, no matter how many women are assigned. Many software tasks have this characteristic because of the sequential nature of debugging. In tasks that can be partitioned but which require communication among the subtasks, the effort of communication must be added to the amount of work to be done. […] Oversimplifying outrageously, we state Brooks’s Law: Adding manpower to a late software project makes it later.
After failing to win several arguments on this point, the engineers became exasperated and decided to hold an intervention with the CEO. They each bought a copy of Brooks’ book, brought the CEO into a conference room, and stacked up the copies of the book, telling him, It is extremely urgent that you read this book. We’ve bought you many copies so that you might read it faster. They made their point.
If you find yourself on a software project where management keeps piling on people to make it go faster, make the argument first. If it fails, employ the BigBook Technique and hammer home the point. (Disclaimer: no, O’Reilly didn’t publish Brooks’ book…) There’s no excuse for a company producing any kind of software to make this mistake: Brooks’ book was published in 1975.