The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is so difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems.
No other part of the work so cripples the resulting system if done wrong.
No other part is more difficult to rectify later.
Therefore the most important function that software builders do for their clients is the iterative extraction and refinement of the product requirements. For the truth is, the clients do not know what they want. They usually do not know what questions must be answered, and they almost never have thought of the problem in the detail that must be specified. …
Complex software systems are, moreover, things that act….the dynamics of that action are hard to imagine.
–The Mythical Man-Month, Fred Brooks
One of the defining texts in the literature of software engineering, MM-M is distinguished both by its initial intelligence and by the iterative nature of its publication history. Brooks did not simply reissue the 1975 book with new afterwords or introductions; he applied the principles of continuous delivery to his own prose arguments, documenting the strongest objections to his initial presentation, incorporating fixes, updating references, and documenting the alterations. This alone is admirable.
What’s more remarkable is that in its major rereleases–1986 and 1995–MM-M didn’t have to change much. Even as the world of computing completely transformed from specialized business systems in the mid70s to a thriving personal computer market and associated start-up culture in the mid80s, with the “shrink-wrapped” software boom of the mid90s looming over the consumer market, Brooks’s initial insights into engineering stayed ahead of their time.
He anticipated the advent of agile development as opposed to waterfall methodologies.
He foresaw the importance of more abstract, or higher, programming languages, and the movement toward object-oriented programming.
He knew that by the late 70s, all the low-hanging fruit had already been picked as far as productivity gains *from an engineering standpoint,* with the consequence that even as hardware and software proliferated into the workplace, bringing efficiencies for ever lower prices, the creation of software itself was heading for a prolonged stagnation.
He saw that a good designer is 10x more valuable and productive than an average designer, and that good designers were as rare, if not rarer, than good managers. (This was controversial, and it may still be.)
Most famously, Brooks argued that organizations could not accelerate the delivery of software products and systems by throwing more bodies at the job…hence the book’s title.
The argument is that some tasks are partitionable, meaning they scale linearly. If one man can shear 20 sheep in an hour, two can complete the task in just about half the time.
Other tasks are not partitionable. A woman takes nine months to carry a fetus to term. A second woman concurrently pregnant can double the output in the same amount of time, but two women on one pregnancy cannot halve the time required. Brooks says software design and construction is mostly non-partitionable.
Three major reasons:
-one is that the daily communication necessary to keep development synchronized exponentiates with additional bodies. While a two-person team can only have one conversation, a four-person team may be having SIX different 1:1 conversations and FOUR different threeway conversations every damn day.
-another is that adding developers to a project later in the game means an immense amount of “catching up” before they can effectively contribute lines of code, and that catching up is the responsibility of the active team; it therefore drains the productivity of the coders you already had working, potentially for multiple weeks
-most of all, in tens of thousands of lines of code, there are thousands of subtle choices reflective of individual style, instinct and training; six coders who learned Objective-C in the same coding dojo will nonetheless execute it in six idiosyncratic ways, and the more discrepancies you have within a coherent part of your codebase, the likelier it is that you are introducing incompatibilities and bugs that will require extensive effort to de-bug later on
A business study done many years after the book’s initial publication applied rigorous statistical analysis to a wide cross-sample of software design projects, and distilled Brooks’s insight into an equation: namely, once you have realistically estimated the man-months necessary to deliver on your identified requirements, the cost-optimum schedule time to first shipment is T=2.5(MM)^⅓. Pretty cool! Optimal timing is 2.5 times the cubic root of your man-months. You can ship 1000 man-months’ work in 25 months–a 40x acceleration. But 8 man-months’ work, optimally goes out in 5 months–only a 1.6x dividend. What that cube root is expressing, in effect, is that gigantic projects allow you to break out multiple subsystems into happy, USMC-style teams of three. This is by no means an iron law of the universe, but it’s not to be disobeyed casually.
Now here’s where the other most famous part of MM-M comes in. Everyone nowadays has a pet theory on where that initial shipment falls within the total project timeline, because of course in iterative development you’re shipping beta versions of individual components and surfacing bugs to fix prior to a total integration and user acceptance testing. The more DevOps-y a shop, the closer to a quarter of the total timeline they’ll trip to peg that initial shipment.
Brooks says it’s halfway, and he breaks it down into these four phases.
ONE-THIRD of the process for requirements and design
ONE-SIXTH for coding
ONE-QUARTER for component testing and debugging
ONE-QUARTER for system integration and user acceptance testing
Brooks also makes a point of saying that when it comes specifically to federal software contracting, contractors who have overestimated their timeline will know within the first two weeks of a well mileposted project schedule that they’re ahead of the game….and barring catastrophe, you’ll stay that way. The flip side of this coin is that if you have underestimated your timeline, it is impossible to recover from your first missed milestone, and the most prudent course is to re-negotiate the entire contract immediately.
