Finding a history for software engineering

IEEE Annals of the History of Computing

Volumn 26, Issue 1, 2004, Pages 8-19

  Mahoney, Michael S ^a  

^a PRINCETON UNIVERSITY   (United States)

Author keywords

[No Author keywords available]

Indexed keywords

COMPUTER SCIENCE; ENTERPRISE RESOURCE PLANNING; INDUSTRIAL APPLICATIONS; PROFESSIONAL ASPECTS;

HISTORICAL MODELS; SOFTWARE ENGINEERS;

SOFTWARE ENGINEERING;

EID: 1842426183     PISSN: 10586180     EISSN: None     Source Type: Journal    
DOI: 10.1109/MAHC.2004.1278847     Document Type: Article

References (58)

1. W. Humphrey, "The Software Engineering Process: Definition and Scope," Representing and Enacting the Software Process: Proc. 4th Int'l Software Process Workshop, ACM Press, 1989, p. 82.
2. M. Shaw, "Prospects for an Engineering Discipline of Software," IEEE Software, vol. 7, no. 6, Nov. 1990, p. 15.
3. Indeed, this article stems from just such an address, delivered to ACM SIGSOFT's 9th Foundations of Software Engineering Conference (FSEC 9) in 1998.
4. See, for example, A.D. Abbott, The System of Professions: An Essay on the Division of Expert Labor, Univ. of Chicago Press, 1988.
5. For a recent discussion of the question, see The History of Software Engineering (Report of the Dagstuhl Seminar no. 9635, W. Aspray, R. Keil-Slawik, and D. Parnas, eds., 1996; available online at www.dagstuhl.de/9635/Report/)
6. J.E. Tomayko, "Software as Engineering" with commentaries by A. Endres and B.E. Seely, History of Computing: Software Issues, U. Hashagen, R. Keil-Slawik, and A. Norberg, eds., Springer Verlag, 2002.
7. M. Shaw of Carnegie Mellon University and the Software Engineering Institute took this approach explicitly in "Prospects for an Engineering Discipline of Software," IEEE Software, vol. 7, no. 6, Nov. 1990, pp. 15-24, in which she proposed a historical model of the professionalization of engineering based primarily on the development of chemical engineering.
8. Her diagram of the process reappeared in enhanced form in W.W. Gibbs, "Software's Chronic Crisis," Scientific Am., vol. 271, no. 3, Sept. 1994, pp. 86-95; on p. 92.
9. For example, at the first NATO conference (see below), R. Graham of Bell Labs remarked that "we build systems like the Wright brothers built airplanes - build the whole thing, push it off the cliff, let it crash, and start over again" (Software Engineering, Concepts and Techniques: Proc. NATO Conferences, P. Naur, B. Randell, and J.N. Buxton, eds., Petrocelli, 1976, p. 7).
10. Historians of technology know that the Wright Brothers' successful flight was in fact the culmination of a carefully planned, theoretically and empirically informed, program of research and development. In particular, they had a relatively clear idea of what problems they had to solve and of how they might go about solving them. Whether or not their approach might have served as a useful example for fledgling of software engineers, it does not seem prima facie to constitute a negative example.
11. Software Engineering: Report on a conf. sponsored by the NATO Science Committee, Garmisch, Germany, 7th to 11th October 1968, P. Naur and B. Randell, eds., Scientific Affairs Division, NATO, 1969, p. 13.
12. The report was republished, toegether with the report on the second conference in Rome the following year, in Software Engineering: Concepts and Techniques. Proc. NATO Conferences, P. Naur, B. Randell, and J.N. Buxton, eds., Petrocelli, 1976. Available at http://homepages.cs.ncl.ac.uk/brian.randell/NATO/.
13. On the formation of the agendas of theoretical computer science, see M.S. Mahoney, "Software as Science - Science as Software," History of Computing: Software Issues, U. Hashagen, R. Keil-Slawik, and A. Norberg, eds., Springer Verlag, 2002, pp. 25-48.
14. "Myth" here should be taken in the sense of a story told by a community to account for why it does things the way it does. The story may be more or less factually accurate, but its function does not depend on it.
15. Edsgar W. Dijkstra was the foremost proponent of this view.
16. J. McCarthy, "Towards a Mathematical Science of Computation," Proc. International Federation of Information Processing (IFIP) Congress (IFIP 62), North-Holland, 1963, p. 21.
17. J. McCarthy, "A Basis for a Mathematical Theory of Computation," Proc. Western Joint Computer Conf., vol. 19, May 1961, Spartan Books, pp. 225-238, reprinted, with corrections and an added 10th section, in Computer Programming and Formal Systems, P. Braffort and D. Hirschberg, eds., North-Holland, 1963, pp. 33-70.
18. J. McCarthy, "A Basis for a Mathematical Theory," p. 33.
19. ibid., p. 34.
20. McCarthy argued that none of the three then-current (1961) directions of research into the mathematics of computing held much promise of such a science. Numerical analysis was too narrowly focused. The theory of computability set a framework into which any mathematics of computation would have to fit, but it focused on what was unsolvable rather than seeking positive results, and its level of description was too general to capture actual algorithms. Finally, the theory of finite automata, though it operated at the right level of generality, exploded in complexity with the size of current computers. As he explained in another article, "... [T]he fact of finiteness is used to show that the automation will eventually repeat a state. However, anyone who waits for an IBM 7090 to repeat a state, solely because it is a finite automation, is in for a very long wait." ("Towards a Mathematical Science of Computation," Proc. IFIP Congress [IFIP 62], North-Holland, 1963, p. 22).
21. C.A.R. Hoare, "Programming: Sorcery or Science?" IEEE Software, vol. 1, no. 2, Mar. 1984, pp. 5-16. Perhaps only coincidentally, the article included a photograph of the room in which Kepler died (p. 14).
22. For an overview, see M.S. Mahoney, "The Structures of Computation," The First Computers - Histories and Architectures, R. Rojas and U. Hashagen, eds., MIT Press, 2000.
23. P. Naur et al., Software Engineering, p. 147.
24. B.W. Arden, ed., What Can Be Automated? The Computer Science and Engineering Research Study (COSERS), MIT Press, 1980, p. 139. The committee consisted of R.M. Karp (chair; Univ. of California, Berkeley), Z. Manna (Stanford Univ.), A.R. Meyer (MIT), J.C. Reynolds (Syracuse Univ.), R.W. Ritchie (Univ. of Washington), J.D. Ullman (Stanford Univ.), and S. Winograd (IBM Research).
25. B. Boehm, "Software Engineering," IEEE Trans. Computers, vol. C-25, no. 12, Dec. 1976, pp. 1226-1241 (reprinted in Milestones in Software Evolution, P.W. Oman and T.G. Lewis, eds., IEEE Computer Soc. Press, 1990, p. 54-69). An early leader in the field of software metrics, Boehm later developed Cocomo, a system for estimating the cost of software projects and wrote the leading text in the subject, Software Engineering Economics.
26. B. Boehm, "Software and its Impact: A Quantitative Assessment," Datamation, vol. 19, 1973, pp. 48-59.
27. B. Boehm, "Software Engineering," p. 67. Boehm's footnote to "technicians" is worth repeating here. "For example, a recent survey of 14 installations in one large organization produced the following profile of its 'average coder': 2 years college-level education, 2 years software experience, familiarity with 2 programming languages and 2 applications, and generally introverted, sloppy, inflexible, 'in over his head,' and undermanaged. Given the continuing increase in demand for software personnel, one should not assume that this typical profile will improve much. This has strong implications for effective software engineering technology which, like effective software, must be well-matched to the people who use it."
28. F.L. Bauer, "Software Engineering," Information Processing 71, North-Holland, 1972, pp. 530-538. Reprinted in Advanced Course in Software Engineering, F.L. Bauer, ed., Springer-Verlag, 1973, pp. 522-545; the reprint did not include Bauer's playful parody of a computer scientist's design of a three-prong hay fork.
29. M. D. McIlroy, "Mass Produced Software Components," in Naur and Randell, pp. 138-150. At the time, McIlroy was one of the representatives of Bell labs to the Multics project at MIT, where he worked on the semantics of PL/I. He subsequently oversaw the development of Unix, to which he contributed the notion of "pipes," which allows the chaining of programs, each taking as its input the output of its predecessor.
30. N. Rosenberg, "Technological Change in the Machine Tool Industry, 1840-1910," J. Economic History vol. 23, 1963, pp. 414-443; reprinted in N. Rosenberg, Perspectives on Technology, Cambridge Univ. Press., 1976, chap. 1.
31. Conversation with McIlroy, 1989.
32. J.B. Dennis, "Modularity," in Bauer, Advanced Course on Software Engineering, chap. 3.A, p. 128.
33. B.J. Cox, "Planning the Software Industrial Revolution," IEEE Software, vol. 7, no. 6, Nov. 1990, pp. 25-33.
34. P. Wegner, "Capital-Intensive Software Technology," IEEE Software, vol. 1, no. 3, July 1984, pp. 7-45.
35. Both Wegner and Jones have told me that their editors, not they, chose the pictures in question. Thus, the analogy was widely shared in the larger community.
36. F.L. Bauer, "Software Engineering," p. 532.
37. Ibid., p. 533.
38. R.W. Bemer, "Position Paper for Panel Discussion [on] the Economics of Program Production," Information Processing 68, North-Holland, 1969, vol. II, p. 1626.
39. In the now classic, Taylorism at Watertown Arsenal: Scientific Management in Action, 1908-1915, Harvard Univ. Press, 1960; reprinted as Scientific Management in Action: Taylorism at Watertown Arsenal, 1908-1915, Princeton Univ. Press, 1985, H.G.J. Aitken listed Taylor's six "solutions of enduring significance" (p. 29): the planned routing and scheduling of work in progress, leading to the assembly line and continuous flow production; systematic inspection procedures between operations; printed jobs and instruction cards; refined cost-accounting techniques; systematization of store procedures, purchasing, and inventory control; and "functional foremanship," which was the only element not to gain general acceptance. Taylor got little credit from historians for these things, yet "these inconspicuous innovations have probably exercised a more far-reaching influence on industrial practice than has the conspicuous innovation of stop-watch time study." Taylor and Taylorism have attracted renewed attention from historians in recent decades
40. see in particular D. Nelson, ed., A Mental Revolution: Scientific Management Since Taylor, Ohio State Univ. Press, 1992
41. S.P. Waring, Taylorism Transformed: Scientific Management since 1945, Univ. North Carolina Press, 1991.
42. R. Kanigel's The One Best Way: Frederick Winslow Taylor and the Enigma of Efficiency (Viking Press, 1997) is a full and informative biography.
43. That science constituted the famous "one best way" on which Taylor's system rested.
44. F.W. Taylor, The Principles of Scientific Management, Harper, 1911; reprinted Norton, 1967, pp. 36-37.
45. W.W. Agresti, "Software Engineering as Industrial Engineering," Software Eng. Notes, vol. 6, no. 5, 1981, pp. 11-12. I thank Michael Cusumano for drawing my attention to this article. Agresti later moved to Computer Sciences Corp. and then to MITRE Corp.
46. L.J. Osterweil, "Software Processes are Software Too," Proc. 9th Int'l Conf. Software Eng. (ICSE 9), IEEE Computer Soc. Press, 1987, pp. 2-13. At ICSE 19, Osterweil's paper was recognized as the most influential paper of ICSE 9.
47. W.S. Humphrey, "The Personal Software Process: Status and Trends," IEEE Software, vol. 17, no. 6, Nov./Dec. 2000, p. 72.
48. F.P. Brooks, Jr., The Mythical Man-Month: Essays on Software Engineering, Addison-Wesley, 1975, pp. 47-48.
49. D.H. Brandon, "The Economics of Computer Programming," On the Management of Computer Programming, G.F. Weinwurm, ed., Auerbach, 1970, chap. 1. Brandon evidently viewed management through Taylorist eyes, but he was clearsighted enough to see that computer programming failed to meet the prerequisites for scientific management.
50. For an analysis of why testing was so unreliable, see R.N. Reinstedt, "Results of a Programmer Performance Prediction Study," IEEE Trans. Eng. Management, Dec. 1967, pp. 183-187
51. G.M. Weinberg, The Psychology of Computer Programming, Van Nostrand Reinhold, 1971, chap. 9.
52. M. Cusumano, Japan's Software Factories, pp. 147-148
53. the quotation is from the description of the SDC software factory by H. Bratman and T. Court, "Elements of the Software Factory: Standards, Procedures, and Tools," in Software Engineering Techniques, Infotech Int'l, 1977, p. 137.
54. For a historical overview of the concept, see M. Cusumano, "Shifting Economies: From Craft Production to Flexible Systems and Software Factories," Research Policy, vol. 21, 1992, pp. 453-480.
55. H. Ford, My Life and Work, Doubleday, 1922, pp. 82-83.
56. See B. Blum, "Understanding the Software Paradox," ACM SIGSOFT Software Engineering Notes, vol. 10, no. 1, 1985, pp. 43-47. Blum attributes the notion to L.G. Stucki.
57. Software Engineering Techniques: Report on a conference sponsored by the NATO Science Committee, Rome, Italy, 27th to 31st October 1969, J.N. Buxton and B. Randell, eds., NATO Science Committee, 1969, p. 12.
58. For a review of the architectural model, see J.O. Coplien, "Reevaluating the Architectural Metaphor: Toward Piecemeal Growth," IEEE Software, vol. 16, no. 5, Sep./Oct. 1999, pp. 40-44.