Software systems are perhaps the most intricate and complex of the things humanity makes

The Mythical Man-Month by Frederick P. Brooks is much in the news at the moment given the regrettable circumstances of the deployment of Healthcare.gov. Having been responsible to a client for the deployment of a 27 country, three continent, 50 business units, multiple languages, hundreds of systems, solution to Y2K with a hard stop delivery date (1/1/00) which included a major organizational divestiture in the midst of the project and which was initiated concerningly near to the hard stop date, I have every sympathy for the programmers of Healthcare.gov. That said, as complex as their task was, it was certainly achievable at levels of quality and reliability much higher than was delivered.

Brooks is the man that has probably best synthesized the panoply of issues associated with big systems creation, deployment and management. There are other, more detailed or more current treatments of elements of the process but he does a good job of an overview. In the second edition of his book in 1995, he added a chapter outlining his major propositions, inviting others to more rigorously test what he was proposing as true. Brooks states that "Software systems are perhaps the most intricate and complex of the things humanity makes" and he is not far wrong as software is intended to both mimic human systems as well as make up for the fallibility and errors inherent in human systems.

The whole book is worth reading and in particular, Chapter 18, the summary of propositions. Excerpted below are the fifteen propositions and snippets of Brooks' commentary on each.

The Tar Pit

1.1 A programming systems product takes about nine times as much effort as the component programs written separately for private use. I estimate that productizing imposes a factor of three; and that designing, integrating, and testing components into a coherent system imposes a factor of three; and that these cost components are essentially independent of each other.

The Mythical Man-Month

2.1 More programming projects have gone awry for lack of calendar time than for all other causes combined.
2.2 Good cooking takes time; some tasks cannot be hurried without spoiling the result.
2.3 All programmers are optimists: "All will go well."
2.4 Because the programmer builds with pure thought-stuff, we expect few difficulties in implementation.
2.5 But our ideas themselves are faulty, so we have bugs.
2.11 Brooks's Law: Adding manpower to a late software project makes it later.

The Surgical Team

3.1 Very good professional programmers are ten times as productive as poor ones, at same training and two-year experience level. (Sackman, Grant, and Erickson)
3.3 A small sharp team is best—as few minds as possible.
3.4 A team of two, with one leader, is often the best use of minds.
3.5 A small sharp team is too slow for really big systems.
3.6 Most experiences with really large systems show the brute-force approach to scaling up to be costly, slow, inefficient, and to produce systems that are not conceptually integrated.

Aristocracy, Democracy, and System Design

4.1 "Conceptual integrity is the most important consideration in system design."
4.3 To achieve conceptual integrity, a design must proceed from one mind or a small group of agreeing minds.
4.5 "If a system is to have conceptual integrity, someone must control the concepts. That is an aristocracy that needs no apology."

The Second-System Effect

5.1 Early and continuous communication can give the architect good cost readings and the builder confidence in the design, without blurring the clear division of responsibilities.

Passing the Word

6.1 Even when a design team is large, the results must be reduced to writing by one or two, in order that the minidecisions be consistent.
6.3 One needs both a formal definition of a design, for precision, and a prose definition for comprehensibility.

Why Did the Tower of Babel Fail?

7.2 "Schedule disaster, functional misfit, and system bugs all arise because the left hand doesn't know what the right hand is doing." Teams drift apart in assumptions.

Calling the Shot

8.2 Data for building isolated small systems are not applicable to programming systems projects.

8.2 Data for building isolated small systems are not applicable
to programming systems projects.
Ten Pounds in a Five-Pound Sack

9.6 On large teams, subteams tend to suboptimize to meet their own targets rather than think about the total effect on the user. This breakdown in orientation is a major hazard of large projects.

The Documentary Hypothesis

10.1 "The hypothesis: Amid a wash of paper, a small number of documents become the critical pivots around which every project's management revolves. These are the manager's chief personal tools."

Plan to Throw One Away

11.1 Chemical engineers have learned not to take a process from the lab bench to the factory in one step, but to build a pilot plant to give experience in scaling quantities up and operating in nonprotective environments.

Sharp Tools

12.1 The manager of a project needs to establish a philosophy and set aside resources for the building of common tools, and at the same time to recognize the need for personalized tools.

The Whole and the Parts

13.2 Vyssotsky says "Many, many failures concern exactly those aspects that were never quite specified."
13.3 Long before any code itself, the specification must be handed to an outside testing group to be scrutinized for completeness and clarity. The developers themselves cannot do this. (Vyssotsky)

Hatching a Catastrophe

14.1 "How does a project get to be a year late? . . . One day at a time."
14.2 Day-by-day schedule slippage is harder to recognize, harder to prevent, and harder to make up than calamities.

The Other Face

15.1 For the program product, the other face to the user, the documentation, is fully as important as the face to the machine.
15.2 Even for the most private of programs, prose documentation is necessary, for memory will fail the user-author.