Brooks, Frederick P. The Mythical Man-Month. Addison-Wesley, anniversary edition, July 1995. ISBN 0201835959.
If a woman can make a baby in nine months, can nine women make a baby in a month? A classic discussion of team structures and gestative processes in software engineering.
Numerous managers I've had in industry did not realize that, among many other points brought out in this book:
Adding manpower to a late software project makes it later.Much of the time, good software is a gestative process. Like making wine, it cannot be rushed if you want quality.
But this very idea makes budget-oriented managers crazy. So how does one cope? Brooks has a lot of good ideas (as does Peopleware).
One of the parts of this book that most interested me was his discussion of team structures. The contrast between the memos-and-meetings world of Hewlett Packard in the early 1970s and the startup atmosphere at Tandem in 1975 convinced me that highly compartmentalized teams aren't as productive. When you have a problem with a part of the project that is someone else's responsibility, you need to be able to walk a short distance to their desk and thrash it out with them right away. Writing memos and then playing around for hours or days waiting for a reply doesn't cut it.
At Tandem, then, the concept was sort of like a troop of samurai: experts in individual combat who are psychically robust. The robustness is necessary because any of your co-workers must be able to tell you when your ideas won't work or when they have a better idea. If you get too emotionally attached to your design decisions, you lose fluidity.
One of my signs of a healthy team is that design decisions are made on technical merit alone. If the outcome depends on other factors (e.g., the person higher on the org chart wins all arguments), you've got trouble. Sometimes there's more than one apparently feasible solution, and in that case the final decision should lie with the person that has to build it.
But at Tandem the idea, at least in the early days before the demand for sheer numbers of top-rank software engineers exceeded the local talent pool, was that you only hired the best and most experienced people, with a long track record of successes. When you're running on limited venture capital, you can't afford any losers.
Brooks, by contrast, proposes some interesting team structures that allow you to get the most out of an assortment of people with different amounts of different talents. His ``surgical team'' approach states that one person will write most or all of the code, and for that position you need a real pro who is also somewhat of a generalist (not just programming, but also human factors and psychology). But he also comes up with team roles for people whose talents are less developed or more narrowly focused.
Another point from Brooks that resonates with my experience is his point that conceptual integrity is an absolute requirement for successful solutions.
The HP 3000 operating system was designed by a team of fourteen. There was no one person who understood the whole design, and this led to serious performance problems. It was easy for small groups to make decisions that cost just a few more disk accesses. But when all those little decisions were added together, the performance was atrocious.
One of the complaints was that logging in took too long. So the lab set up a machine that had a probe in its guts that pulsed every time the disk did a seek. This probe was connected to an HP counter sitting on top of the processor cabinet. One day they did a simple test: they let the machine stabilize, zeroed the counter, and logged in. There were some bets about how many disk accesses this would generate. Estimates ranged from a few dozen to maybe 200. Nobody guessed the actual number, which was over 1000.
The problem here was that nobody saw the big picture, so no one could make intelligent guesses about performance.
By contrast, the operating system for the Tandem T/16 was done mainly by two people: Joel Bartlett and Dennis McEvoy split the design into `I/O' (input-output devices and channels and file systems) and `not I/O' (everything else---the kernel, the dispatcher, and so on). (Tom Blease helped some with memory management.) But with two people, it's much less likely that little performance horrors could hide in odd corners of the design.
To sum up, there has to be at least one person who can see the big picture of the design. In a complete computer system, that means one person (the systems-level architect) should be able to understand the tradeoffs between putting functionality into hardware and putting them into software. One person (the operating system architect) should be able to understand the whole operating system. One person (the hardware architect) should see the whole hardware design.