1. Ershov considers this not only a woe, but also a part of the joy. A. P. Ershov, "Aesthetics and the human factor in programming," CACM, 15, 7 (July, 1972), pp. 501–505.
1. V. A. Vyssotsky of Bell Telephone Laboratories estimates that a large project can sustain a manpower buildup of 30 percent per year. More than that strains and even inhibits the evolution of the essential informal structure and its communication pathways discussed in Chapter 7.
F. J. Corbatò of MIT points out that a long project must anticipate a turnover of 20 percent per year, and these must be both technically trained and integrated into the formal structure.
2. C. Portman of International Computers Limited says, "When everything has been seen to work, all integrated, you have four more months work to do." Several other sets of schedule divisions are given in Wolverton, R. W., "The cost of developing large-scale software," IEEE Trans. on Computers, C-23, 6 (June, 1974) pp. 615–636.
3. Figures 2.5 through 2.8 are due to Jerry Ogdin, who in quoting my example from an earlier publication of this chapter much improved its illustration. Ogdin, J. L., "The Mongolian hordes versus superprogrammer," Infosystems (Dec., 1972), pp. 20–23.
1. Sackman, H., W. J. Erikson, and E. E. Grant, "Exploratory experimental studies comparing online and offline programming performance," CACM, 11, 1 (Jan., 1968), pp. 3–11.
2. Mills, H., "Chief programmer teams, principles, and procedures," IBM Federal Systems Division Report FSC 71–5108, Gaithersburg, Md., 1971.
3. Baker, F. T., "Chief programmer team management of production programming," IBM Sys. J., 11, 1 (1972).
1. Eschapasse, M., Reims Cathedral, Caisse Nationale des Monuments Historiques, Paris, 1967.
2. Brooks, F. P., "Architectural philosophy," in W. Buchholz (ed.), Planning A Computer System. New York: McGraw-Hill, 1962.
3. Blaauw, G. A., "Hardware requirements for the fourth generation," in F. Gruenberger (ed.), Fourth Generation Computers. Englewood Cliffs, N.J.: Prentice-Hall, 1970.
4. Brooks, F. P., and K. E. Iverson, Automatic Data Processing, System/360 Edition. New York: Wiley, 1969, Chapter 5.
5. Glegg, G. L., The Design of Design. Cambridge: Cambridge Univ. Press, 1969, says "At first sight, the idea of any rules or principles being superimposed on the creative mind seems more likely to hinder than to help, but this is quite untrue in practice. Disciplined thinking focuses inspiration rather than blinkers it."
6. Conway, R. W., "The PL/C Compiler," Proceedings of a Conf. on Definition and Implementation of Universal Programming Languages. Stuttgart, 1970.
7. For a good discussion of the necessity for programming technology, see C. H. Reynolds, "What's wrong with computer programming management?" in G. F. Weinwurm (ed.), On the Management of Computer Programming. Philadelphia: Auerbach, 1971, pp. 35–42.
1. Strachey, C., "Review of Planning a Computer System," Comp. J., 5, 2 (July, 1962), pp. 152–153.
2. This applies only to the control programs. Some of the compiler teams in the OS/360 effort were building their third or fourth systems, and the excellence of their products shows it.
3. Shell, D. L., "The Share 709 system: a cooperative effort"; Greenwald, I. D., and M. Kane, "The Share 709 system: programming and modification"; Boehm, E. M., and T. B. Steel, Jr., "The Share 709 system: machine implementation of symbolic programming"; all in JACM, 6, 2 (April, 1959), pp. 123–140.
1. Neustadt, R. E., Presidential Power. New York: Wiley, 1960, Chapter 2.
2. Backus, J. W., "The syntax and semantics of the proposed international algebraic language." Proc. Intl. Conf. Inf. Proc. UNESCO, Paris, 1959, published by R. Oldenbourg, Munich, and Butterworth, London. Besides this, a whole collection of papers on the subject is contained in T. B. Steel, Jr. (ed.), Formal Language Description Languages for Computer Programming. Amsterdam: North Holland, (1966).
3. Lucas, P., and K. Walk, "On the formal description of PL/I," Annual Review in Automatic Programming Language. New York: Wiley, 1962, Chapter 2, p. 2.
4. Iverson, K. E., A Programming Language. New York: Wiley, 1962, Chapter 2.
5. Falkoff, A. D., K. E. Iverson, E. H. Sussenguth, "A formal description of System/360," IBM Systems Journal, 3, 3 (1964), pp. 198–261.
6. Bell, C. G., and A. Newell, Computer Structures. New York: McGraw-Hill, 1970, pp. 120–136, 517–541.
7. Bell, C. G., and A. Newell, Computer Structures. New York: McGraw-Hill, 1970, pp. 120–136, 517–541.
8. Bell, C. G., private communication.
1. Parnas, D. L., "Information distribution aspects of design methodology," Carnegie-Mellon Univ., Dept. of Computer Science Technical Report, February, 1971.
2. Copyright 1939, 1940 Street & Smith Publications, Copyright 1950, 1967 by Robert A. Heinlein. Published by arrangement with Spectrum Literary Agency.
1. Sackman, H., W. J. Erikson, and E. E. Grant, "Exploratory experimentation studies comparing online and offline programming performance," CACM, 11, 1 (Jan., 1968), pp. 3–11.
2. Nanus, B., and L. Farr, "Some cost contributors to large-scale programs," AFIPS Proc. SJCC, 25 (Spring, 1964), pp. 239–248.
3. Weinwurm, G. F., "Research in the management of computer programming," Report SP-2059, System Development Corp., Santa Monica, 1965.
4. Morin, L. H., "Estimation of resources for computer programming projects," M. S. thesis, Univ. of North Carolina, Chapel Hill, 1974.
5. Portman, C., private communication.
6. An unpublished 1964 study by E. F. Bardain shows programmers realizing 27 percent productive time. (Quoted by D. B. Mayer and A. W. Stalnaker, "Selection and evaluation of computer personnel," Proc. 23rd ACM Conf., 1968, p. 661.)
7. Aron, J., private communication.
8. Paper given at a panel session and not included in the AFIPS Proceedings.
9. Wolverton, R. W.; "The cost of developing large-scale software," IEEE Trans. on Computers, C-23, 6 (June, 1974) pp. 615–636. This important recent paper contains data on many of the issues of this chapter, as well as confirming the productivity conclusions.
10. Corbatò, F. J., "Sensitive issues in the design of multi-use systems," lecture at the opening of the Honeywell EDP Technology Center, 1968.
11. W. M. Taliaffero also reports a constant productivity of 2400 statements/year in assembler, Fortran, and Cobol. See "Modularity. The key to system growth potential," Software, 1, 3 (July 1971) pp. 245–257.
12. E. A. Nelson's System Development Corp. Report TM-3225, Management Handbook for the Estimation of Computer Programming Costs, shows a 3-to-1 productivity improvement for high-level language (pp. 66–67), although his standard deviations are wide.
1. Brooks, F. P. and K. E. Iverson, Automatic Data Processing, System/360 Edition. New York: Wiley, 1969, Chapter 6.
2. Knuth, D. E., The Art of Computer Programming, Vols. 1–3. Reading, Mass.: Addison-Wesley, 1968, ff.
1. Conway, M. E., "How do committees invent?" Datamation, 14, 4 (April, 1968), pp. 28–31.
1. Speech at Oglethorpe University, May 22, 1932.
2. An illuminating account of Multics experience on two successive systems is in F. J. Corbatò, J. H. Saltzer, and C. T. Clingen, "Multics—the first seven years," AFIPS Proc SJCC, 40 (1972), pp. 571–583.
3. Cosgrove, J., "Needed: a new planning framework," Datamation, 17, 23 (Dec., 1971), pp. 37–39.
4. The matter of design change is complex, and I oversimplify here. See J. H. Saltzer, "Evolutionary design of complex systems," in D. Eckman (ed.), Systems: Research and Design. New York: Wiley, 1961. When all is said and done, however, I still advocate building a pilot system whose discarding is planned.
5. Campbell, E., "Report to the AEC Computer Information Meeting," December, 1970. The phenomenon is also discussed by J. L. Ogdin in "Designing reliable software," Datamation, 18, 7 (July, 1972), pp. 71–78. My experienced friends seem divided rather evenly as to whether the curve finally goes down again.
6. Lehman, M., and L. Belady, "Programming system dynamics," given at the ACM SIGOPS Third Symposium on Operating System Principles, October, 1971.
7. Lewis, C. S., Mere Christianity. New York: Macmillan, 1960, p. 54.
1. See also J. W. Pomeroy, "A guide to programming tools and techniques," IBM Sys. J., 11, 3 (1972), pp. 234–254.
2. Landy, B., and R. M. Needham, "Software engineering techniques used in the development of the Cambridge Multiple-Access System," Software, 1, 2 (April, 1971), pp. 167–173.
3. Corbatò, F. J., "PL/I as a tool for system programming," Datamation, 15, 5 (May, 1969), pp. 68–76.
4. Hopkins, M., "Problems of PL/I for system programming," IBM Research Report RC 3489, Yorktown Heights, N.Y., August 5, 1971.
5. Corbatò, F. J., J. H. Saltzer, and C. T. Clingen, "Multics—the first seven years," AFIPS Proc SJCC, 40 (1972), pp. 571–582. "Only a half-dozen areas which were written in PL/I have been recoded in machine language for reasons of squeezing out the utmost in performance. Several programs, originally in machine language, have been recoded in PL/I to increase their maintainability."
6. To quote Corbatò's paper cited in reference 3: "PL/I is here now and the alternatives are still untested." But see a quite contrary view, well-documented, in Henricksen, J. O. and R. E. Merwin, "Programming language efficiency in real-time software systems," AFIPS Proc SJCC, 40 (1972) pp. 155–161.
7. Not all agree. Harlan Mills says, in a private communication, "My experience begins to tell me that in production programming the person to put at the terminal is the secretary. The idea is to make programming a more public practice, under common scrutiny of many team members, rather than a private art."
8. Harr, J., "Programming Experience for the Number 1 Electronic Switching System," paper given at the 1969 SJCC.
1. Vyssotsky, V. A., "Common sense in designing testable software," lecture at The Computer Program Test Methods Symposium, Chapel Hill, N.C., 1972. Most of Vyssotsky's lecture is contained in Hetzel, W. C. (ed.), Program Test Methods. Englewood Cliffs, N.J.: Prentice-Hall, 1972, pp. 41–47.
2. Wirth, N., "Program development by stepwise refinement," CACM 14, 4 (April, 1971), pp. 221–227. See also Mills, H. "Top-down programming in large systems," in R. Rustin (ed.). Debugging Techniques in Large Systems. Englewood Cliffs, N.J.: Prentice-Hall, 1971, pp. 41–55 and Baker, F. T., "System quality through structured programming," AFIPS Proc FJCC, 41-I (1972), pp. 339–343.
3. Dahl, O. J., E. W. Dijkstra and C. A. R. Hoare, Structured Programming. London and New York: Academic Press, 1972. This volume contains the fullest treatment. See also Dijkstra's germinal letter, "GOTO statement considered harmful," CACM, 11, 3 (March, 1968), pp. 147–148.
4. B öhm, C., and A. Jacopini, "Flow diagrams, Turing machines, and languages with only two formation rules," CACM, 9, 5 (May, 1966), pp. 366–371.
5. Codd, E. F., E. S. Lowry, E. McDonough, and C. A. Scalzi, "Multiprogramming STRETCH: Feasibility considerations," CACM, 2, 11 (Nov., 1959), pp. 13–17.
6. Strachey, C., "Time sharing in large fast computers," Proc. Int. Conf. on Info. Processing, UNESCO (June, 1959), pp. 336–341. See also Codd's remarks on p. 341, where he reported progress on work like that proposed in Strachey's paper.
7. Corbatò, F. J., M. Merwin-Daggett, R. C. Daley, "An experimental time-sharing system," AFIPS Proc. SJCC, 2 (1962), pp. 335–344. Reprinted in S. Rosen, Programming Systems and Languages. New York: McGraw-Hill, 1967, pp. 683–698.
8. Gold, M. M., "A methodology for evaluating time-shared computer system usage," Ph.D. dissertation, Carnegie-Mellon University, 1967, p. 100.
9. Gruenberger, F., "Program testing and validating," Datamation, 14, 7 (July, 1968), pp. 39–47.
10. Ralston, A., Introduction to Programming and Computer Science. New York: McGraw-Hill, 1971, pp. 237–244.
11. Brooks, F. P., and K. E. Iverson, Automatic Data Processing, System/360 Edition. New York: Wiley, 1969, pp. 296–299.
12. A good treatment of development of specifications and of system build and test is given by F. M. Trapnell, "A systematic approach to the development of system programs," AFIPS Proc SJCC, 34 (1969) pp. 411–418.
13. A real-time system will require an environment simulator. See, for example, M. G. Ginzberg, "Notes on testing realtime system programs," IBM Sys. J., 4, 1 (1965), pp. 58–72.
14. Lehman, M., and L. Belady, "Programming system dynamics," given at the ACM SIGOPS Third Symposium on Operating System Principles, October, 1971.
1. See C. H. Reynolds, "What's wrong with computer programming management?" in G. F. Weinwurm (ed.), On the Management of Computer Programming. Philadelphia: Auerbach, 1971, pp. 35–42.
2. King, W. R., and T. A. Wilson, "Subjective time estimates in critical path planning—a preliminary analysis," Mgt. Sci., 13, 5 (Jan., 1967), pp. 307–320, and sequel, W. R. King, D. M. Witterrongel, K. D. Hezel, "On the analysis of critical path time estimating behavior," Mgt. Sci., 14, 1 (Sept., 1967), pp. 79–84.
3. For a fuller discussion, see Brooks, F. P., and K. E. Iverson, Automatic Data Processing, System/360 Edition, New York: Wiley, 1969, pp. 428–430.
1. Goldstine, H. H., and J. von Neumann, "Planning and coding problems for an electronic computing instrument," Part II, Vol. 1, report prepared for the U.S. Army Ordinance Department, 1947; reprinted in J. von Neumann, Collected Works, A. H. Taub (ed.), Vol. v., New York: McMillan, pp. 80–151.
2. Private communication, 1957. The argument is published in Iverson, K. E., "The Use of APL in Teaching," Yorktown, N.Y.: IBM Corp., 1969.
3. Another list of techniques for PL/I is given by A. B. Walter and M. Bohl in "From better to best—tips for good programming," Software Age, 3, 11 (Nov., 1969), pp. 46–50.
The same techniques can be use in Algol and even Fortran. D. E. Lang of the University of Colorado has a Fortran formatting program called STYLE that accomplishes such a result. See also D. D. McCracken and G. M. Weinberg, "How to write a readable FORTRAN program," Datamation, 18, 10 (Oct., 1972), pp. 73–77.
1. The essay entitled "No Silver Bullet" is from Information Processing 1986, the Proceedings of the IFIP Tenth World Computing Conference, edited by H.-J. Kugler (1986), pp. 1069–76. Reprinted with the kind permission of IFIP and Elsevier Science B. V., Amsterdam, The Netherlands.
2. Parnas, D. L., "Designing software for ease of extension and contraction," IEEE Trans. on SE, 5, 2 (March, 1979), pp. 128–138.
3. Booch, G., "Object-oriented design," in Software Engineering with Ada. Menlo Park, Calif.: Benjamin/Cummings, 1983.
4. Mostow, J., ed., Special Issue on Artificial Intelligence and Software Engineering, IEEE Trans. on SE, 11, 11 (Nov., 1985).
5. Parnas, D. L., "Software aspects of strategic defense systems," Communications of the ACM, 28, 12 (Dec., 1985), pp. 1326–1335. Also in American Scientist, 73, 5 (Sept.-Oct., 1985), pp. 432–440.
6. Balzer, R., "A 15-year perspective on automatic programming," in Mostow, op. cit.
9. Raeder, G., "A survey of current graphical programming techniques," in R. B. Grafton and T. Ichikawa, eds., Special Issue on Visual Programming, Computer, 18, 8 (Aug., 1985), pp. 11–25.
10. The topic is discussed in Chapter 15 of this book.
11. Mills, H. D., "Top-down programming in large systems," Debugging Techniques in Large Systems, R. Rustin, ed., Englewood Cliffs, N.J., Prentice-Hall, 1971.
12. Boehm, B. W., "A spiral model of software development and enhancement," Computer, 20, 5 (May, 1985), pp. 43–57.
1. Material quoted without citation is from personal communications.
2. Brooks, F. P., "No silver bullet—essence and accidents of software engineering," in Information Processing 86, H. J. Kugler, ed. Amsterdam: Elsevier Science (North Holland), 1986, pp. 1069–1076.
3. Brooks, F. P., "No silver bullet—essence and accidents of software engineering," Computer 20, 4 (April, 1987), pp. 10–19.
4. Several of the letters, and a reply, appeared in the July, 1987 issue of Computer.
It is a special pleasure to observe that whereas "NSB" received no awards, Bruce M. Skwiersky's review of it was selected as the best review published in Computing Reviews in 1988. E. A. Weiss, "Editorial," Computing Reviews (June, 1989), pp. 283–284, both announces the award and reprints Skwiersky's review. The review has one significant error: "sixfold" should be "106."
5. "According to Aristotle, and in Scholastic philosophy, an accident is a quality which does not belong to a thing by right of that thing's essential or substantial nature but occurs in it as an effect of other causes." Webster's New International Dictionary of the English Language, 2d ed., Springfield, Mass.: G. C. Merriam, 1960.
6. Sayers, Dorothy L., The Mind of the Maker. New York: Harcourt, Brace, 1941.
7. Glass, R. L., and S. A. Conger, "Research software tasks: Intellectual or clerical?" Information and Management, 23, 4 (1992). The authors report a measurement of software requirements specification to be about 80% intellectual and 20% clerical. Fjelstadt and Hamlen, 1979, get essentially the same results for application software maintenance. I know of no attempt to measure this fraction for the whole end-to-end task.
8. Herzberg, F., B. Mausner, and B. B. Sayderman. The Motivation to Work, 2nd ed. London: Wiley, 1959.
9. Cox, B. J., "There is a silver bullet," Byte (Oct., 1990), pp. 209–218.
10. Harel, D., "Biting the silver bullet: Toward a brighter future for system development," Computer (Jan., 1992), pp. 8–20.
11. Parnas, D. L., "Software aspects of strategic defense systems," Communications of the ACM, 28, 12 (Dec., 1985), pp. 1326–1335.
12. Turski, W. M., "And no philosophers' stone, either," in Information Processing 86, H. J. Kugler, ed. Amsterdam: Elsevier Science (North Holland), 1986, pp. 1077–1080.
13. Glass, R. L., and S. A. Conger, "Research Software Tasks: Intellectual or Clerical?" Information and Management, 23, 4 (1992), pp. 183–192.
14. Review of Electronic Digital Computers, Proceedings of a Joint AIEE-IRE Computer Conference (Philadelphia, Dec. 10–12, 1951). New York: American Institute of Electrical Engineers, pp. 13–20.
15. Ibid., pp. 36, 68, 71, 97.
16. Proceedings of the Eastern Joint Computer Conference, (Washington, Dec. 8–10, 1953). New York: Institute of Electrical Engineers, pp. 45–47.
17. Proceedings of the 1955 Western Joint Computer Conference (Los Angeles, March 1–3, 1955). New York: Institute of Electrical Engineers.
18. Everett, R. R., C. A. Zraket, and H. D. Bennington, "SAGE—A data processing system for air defense," Proceedings of the Eastern Joint Computer Conference (Washington, Dec. 11–13, 1957). New York: Institute of Electrical Engineers.
19. Harel, D., H. Lachover, A. Naamad, A. Pnueli, M. Politi, R. Sherman, A. Shtul-Trauring, "Statemate: A working environment for the development of complex reactive systems," IEEE Trans. on SE, 16, 4 (1990), pp. 403–444.
20. Jones, C., Assessment and Control of Software Risks. Englewood Cliffs, N.J.: Prentice-Hall, 1994. p. 619.
21. Coqui, H., "Corporate survival: The software dimension," Focus '89, Cannes, 1989.
22. Coggins, James M., "Designing C++ libraries," C++ Journal, 1, 1 (June, 1990), pp. 25–32.
23. The tense is future; I know of no such result yet reported for a fifth use.
25. Huang, Weigiao, "Industrializing software production," Proceedings ACM 1988 Computer Science Conference, Atlanta, 1988. I fear the lack of personal job growth in such an arrangement.
26. The entire September, 1994 issue of IEEE Software is on reuse.
29. Yourdon, E., Decline and Fall of the American Programmer. Englewood Cliffs, N.J.: Yourdon Press, 1992, p. 221.
30. Glass, R. L., "Glass" (column), System Development (January, 1988), pp. 4–5.
1. Boehm, B. W., Software Engineering Economics, Englewood Cliffs, N.J.: Prentice-Hall, 1981, pp. 81–84.
2. McCarthy, J., "21 Rules for Delivering Great Software on Time," Software World USA Conference, Washington (Sept., 1994).
1. Material quoted without citation is from personal communications.
2. On this painful subject, see also Niklaus Wirth "A plea for lean software," Computer, 28, 2 (Feb., 1995), pp. 64–68.
3. Coleman, D., 1994, "Word 6.0 packs in features; update slowed by baggage," MacWeek, 8, 38 (Sept. 26, 1994), p. 1.
4. Many surveys of machine language and programming language command frequencies after fielding have been published. For example, see J. Hennessy and D. Patterson, Computer Architecture. These frequency data are very useful for building successor products, although they never exactly apply. I know of no published frequency estimates prepared before the product was designed, much less comparisons of a priori estimates and a posteriori data. Ken Brooks suggests that bulletin boards on the Internet now provide a cheap method of soliciting data from prospective users of a new product, even though only a self-selected set responds.
5. Conklin, J., and M. Begeman, "gIBIS: A Hypertext Tool for Exploratory Policy Discussion," ACM Transactions on Office Information Systems, Oct. 1988, pp. 303–331.
6. Englebart, D., and W. English, "A research center for augmenting human intellect," AFIPS Conference Proceedings, Fall Joint Computer Conference, San Francisco (Dec. 9–11, 1968), pp. 395–410.
7. Apple Computer, Inc., Macintosh Human Interface Guidelines, Reading, Mass.: Addison-Wesley, 1992.
8. It appears the Apple Desk Top Bus could handle two mice electronically, but the operating system provides no such function.
9. Royce, W. W., 1970. "Managing the development of large software systems: Concepts and techniques," Proceedings, WESCON (Aug., 1970), reprinted in the ICSE 9 Proceedings. Neither Royce nor others believed one could go through the software process without revising earlier documents; the model was put forth as an ideal and a conceptual aid. See D. L. Parnas and P. C. Clements, "A rational design process: How and why to fake it," IEEE Transactions on Software Engineering, SE-12, 2 (Feb., 1986), pp. 251–257.
10. A major reworking of DOD-STD-2167 produced DOD-STD-2167A (1988), which allows but does not mandate more recent models such as the spiral model. Unfortunately, the MILSPECS that 2167A references and the illustrative examples it uses are still waterfall-oriented, so most procurements have continued to use the waterfall, Boehm reports. A Defense Science Board Task Force under Larry Druffel and George Heilmeyer, in their 1994 "Report of the DSB task force on acquiring defense software commercially," has advocated the wholesale use of more modern models.
11. Mills, H. D., "Top-down programming in large systems," in Debugging Techniques in Large Systems, R. Rustin, ed. Englewood Cliffs, N.J.: Prentice-Hall, 1971.
12. Parnas, D. L., "On the design and development of program families," IEEE Trans. on Software Engineering, SE-2, 1 (March, 1976), pp. 1–9; Parnas, D. L., "Designing software for ease of extension and contraction," IEEE Trans. on Software Engineering, SE-5, 2 (March, 1979), pp. 128–138.
13. D. Harel, "Biting the silver bullet," Computer (Jan., 1992), pp. 8–20.
14. The seminal papers on information hiding are: Parnas, D. L., "Information distribution aspects of design methodology," Carnegie-Mellon, Dept. of Computer Science, Technical Report (Feb., 1971); Parnas, D. L., "A technique for software module specification with examples," Comm. ACM, 5, 5 (May, 1972), pp. 330–336; Parnas, D. L. (1972). "On the criteria to be used in decomposing systems into modules," Comm. ACM, 5, 12 (Dec., 1972), pp. 1053–1058.
15. The ideas of objects were initially sketched by Hoare and Dijkstra, but the first and most influential development of them was the Simula-67 language by Dahl and Nygaard.
16. Boehm, B. W., Software Engineering Economics, Englewood Cliffs, N.J.: Prentice-Hall, 1981, pp. 83–94; 470–472.
17. Abdel-Hamid, T., and S. Madnick, Software Project Dynamics: An Integrated Approach, ch. 19, "Model enhancement and Brooks's law." Englewood Cliffs, N.J.: Prentice Hall, 1991.
18. Stutzke, R. D., "A Mathematical Expression of Brooks's Law." In Ninth International Forum on COCOMO and Cost Modeling. Los Angeles: 1994.
19. DeMarco, T., and T. Lister, Peopleware: Productive Projects and Teams. New York: Dorset House, 1987.
20. Pius XI, Encyclical Quadragesimo Anno, [Ihm, Claudia Carlen, ed., The Papal Encyclicals 1903–1939, Raleigh, N.C.: McGrath, p. 428.]
21. Schumacher, E. F., Small Is Beautiful: Economics as if People Mattered, Perennial Library Edition. New York: Harper and Row, 1973, p. 244.
22. Schumacher, op. cit., p. 34.
23. A thought-provoking wall poster proclaims: "Freedom of the press belongs to him who has one."
24. Bush, V., "That we may think," Atlantic Monthly, 176, 1 (April, 1945), pp. 101–108.
25. Ken Thompson of Bell Labs, inventor of Unix, realized early the importance of big screens for programming. He devised a way to get 120 lines of code, in two columns, onto his primitive Tektronix electron-storage tube. He clung to this terminal through a whole generation of small-window, fast tubes.