[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 operator.

[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 shortfall).

[p299] Wirth, N., "Program development by stepwise refinement," CACM 14, 4 (April 1971), pp.221-227