by Frederick Brooks, Addison Wesley, 1995
[p19] Since software construction is inherently a systems effor--an
exercise in complex interrelationsihps--communication effort is great,
and it quickly dominates the decrease in individual task time brought
about by partitioning.
[p55] The second is the most dangerous system a man ever designs.
[p56] For example, OS/360 devotes 26 bytes of the permanently
resident date-turnover routine in proper handling of Decumber 31 on
leap years (when it is Day 366). That might have been left to the
[p76] We quickly decided that each programmer should see
all the material, i.e., should have a copy of the workbook in
his own office.[...] We had available a computer-driven text-editing
system, and this proved invaluable for timely maintenance.
[p94] Programming productivity may be increased as much as five
times when a suitable highlevel language is used.
[p103] Representation is the essence of programming.
[p117] The Only Constancy is Change Itself[...] The first step is to
accept the fact of change as a way of life, rather than an untoward
and annoying exception.
[p117] Far be it from me to suggest that all changes in customer
objectives and requirements must, can, or should be incorporated in the
design. Clearly a threshold has to be established, and it must get
higher and higher as development proceeds, or no product ever appears.
[p122] As a consequence of the introduction of new bugs, program
maintenance requires far more system testing per statement written
than any other programming. Theoretically, after each fix one must
run the entire bank of test cases previously run against the system,
to ensure that it has not been damaged in an obscure way. In
practice, each regression testing must indeed approximate this
theoretical ideal, and it is very costly.
[p122] All repairs tend to destroy the structure, to increase the
entropy and disorder of the system. Less and less effort is spent on
fixing original design flaws; more and more is spent on fixing flaws
introduced by earlier fixes. As time passes, the system becomes less
and less well-ordered. Sooner or later the fixing ceases to gain any
ground. [...] A brand-new, from-the-ground-up redesign is necessary.
[p123] Systems program building is an entropy-decreasing process,
hence inherently metastable. Program maintenance is an
entropy-increasing process, and even its most skillful execution only
delays the subsidence of the system into unfixable obselescence.
[p136] I mystelf find it faster to work out algorithms in APL; then
I translate these to PL/I for matching to the system environment.
[p155] It is more important that milestones by sharp-edged and
unambiguous than that they be easily verifiable by the boss. [...]
2. During the activity, over estimates of duration come
steadily down as the activity proceeds.
[p165] <b>To believe a program.</b> The description of how it is
used must be supplemented with some description of how one knows it is
working. This means test cases.
[p221] The answer is simple. It is because [O-O] has been tied to a
variaety of complex languages. Insetad of teaching people that O-O is
a type of design, and giving them design principles, people have
taught that O-O is the use of a particular tool. We can write good or
bad programs with any tool. Unless we teach people how to design, the
languages matter very little. The result is that people do bad
designs with these languages and get very little value from them. If
the value is small, it won't catch on.
[p268] Since we have a working system at all times:
we can begin user testing very early, and
we can adopt a build-to-budget strategy that protects absolutely
against schedule or budget overruns (at the cost of possible functional
[p299] Wirth, N., "Program development by stepwise refinement," CACM
14, 4 (April 1971), pp.221-227