Chapter 1 THE TAR PIT


·       From Program to Programming Systems Product

















Chapter 2 The Mythical Man-Month


More software projects have gone away for lack of calendar time than for all other causes combined.

1. Optimism

All programmers are optimists. They assume that all will go well. It’s wrong.

There are three stages of creative activities: the idea, the implementation, the interaction.

Our ideas are faulty, so we have bugs. The incompleteness and inconsistencies of our ideas become clear only during implementation.


2. The Man-Month

The Man-Month is a fallacious and dangerous myth, for it implies that men and months are interchangeable. In fact, they are interchangeable commodities only when a task can partitioned among many workers with no communication among them.


Most software are unpartitioned tasks. Therefore, more effort has no effect on the schedule.

For the tasks can be partitioned but require communication among the subtasks, the effort of communication must be added.

The communication efforts include training and intercommunication.


3. System Test

The time required for debugging and system test depends on the number and subtlety of the errors encountered. 0 is the ideal number.


The rules: 1/3 of the schedule for design, 1/3 for coding, ¼ for component testing, and ¼ for system testing.

Testing is usually the most mis-scheduled part of programming.


4. Gutless Estimating

Because we are uncertain about our scheduling estimates, we often lack the courage to defend them stubbornly against management and customer pressure.


5. Regenerative Schedule Disaster

There are four ways to manager the delay.

1) Assume the task must be done on time. Assume only the first part of the task was misestimate.

2) Assume the task must be done on time. Assume the whole estimate was uniformly low.

3) Reschedule

4) Trim the task.


Brooks’s Law: Adding manpower to a late software project makes it later.

Adding people to a software project increases the total effort necessary in three ways: the work and disruption of repartitioning itself, training the new people, and added intercommunication.


Chapter 3 The Surgical Team


1. There are wide productivity variations between good programmers and poor ones.

“Very good professional programmers are ten times as productive as poor ones, at the same training and two-year experience level.”


2. A small sharp team is the best.


3. There is the dilemma:

For efficiency and conceptual integrity ---------- prefer few but good minds;

For large systems ---------- need considerable manpower.


4.One way to solve the dilemma: Mills’s proposal ------ The surgical team.


5. What’s the meaning?

“Instead of each member cutting away on the problem, one does the cutting and the others give him every support that will enhance his effectiveness and productivity.”


6. The organization of the surgical team:

Ø      surgeon (chief programmer);

Ø      copilot ;

Ø      administrator;

Ø      editor;

Ø      two secretaries;

Ø      program clerk;

Ø      toolsmith;

Ø      tester;

Ø      language lawyer.


7. The surgical team organization offers a way to get the product integrity of few minds and the total productivity of many helpers, with radically reduced communication.



Chapter 4

Aristocracy, Democracy, and System Design


4.1 Conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.

4.2 The ratio of function to conceptual complexity is the ultimate test of system design, not just the richness of function.

4.3 To achieve conceptual integrity, a design must proceed from one mind or a small group of agreeing minds.

4.4 The separation of architectural effort from implementation is a very powerful way of getting conceptual integration on very large projects. As Blaauw has said, “Where architecture tells what happens, implementation tells how it is made to happen.”

4.5 If a system is to have conceptual integrity, someone must control the concepts. That is an aristocracy that needs no apology.

4.6 Discipline is good for art. The external provision of an architecture enhances, not cramps, the creative style of an implementing group.

4.7 As Blaauw points out, the total creative effort involves three distinct phases: architecture, implementation, and realization.

4.8 A conceptually integrated system is faster to build and to test.

4.9 Much of software architecture, implementation, and realization can proceed in parallel.


Chapter 5 The Second-System Effect


Add little to little and there will be a big pile


Interactive Discipline for the Architect


q       Remember that the builder has the inventive and creative responsibility for the implementation; so the architect suggests, not dictates;

q       Always be prepared to suggest a way of implementing anything he specifies, and be prepared to accept any other way that meets the objectives as well;

q       Deal quietly and privately in such suggestions;

q       Be ready to forego credit for suggested improvements.


Self-Discipline—The Second-System Effect


An architect’s first work is apt to be spare and clean.


After the first system is finished, the architect, with firm confidence and a demonstrated mastery of that class of systems, is ready to build a second system. This second is the most dangerous system a man ever designs.


The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one.


The second-system effect has another manifestation somewhat different from pure functional embellishment. That is a tendency to refine techniques whose very existence has been made obsolete by changes in basic system assumptions.


How does the architect avoid the second-system effect?


He can be conscious of the peculiar hazards of that system, and exert extra self-discipline to avoid functional ornamentation and to avoid extrapolation of functions that are obviated by changes in assumptions and purposes.


How does the project manager avoid the second-system effect?


He can ask the right questions to ensure that the philosophical concepts and objectives are fully reflected in the detailed design.