, George Washington University
Pages: pp. 66-68
We enjoyed reading the "Events and Sightings" article ( IEEE Annals of the History of Computing, vol. 26, no. 2, 2004, pp. 84-85) in which you described the reconstruction of the Chess-Playing Turk. Unfortunately, the statement you made was not correct: The Chess-Playing Turk was not reconstructed by the Deutsches Museum in Munich but by the Heinz Nixdorf MuseumsForum in Paderborn.
Andreas Stolte, Heinz Nixdorf MuseumsForum; firstname.lastname@example.org
I wholeheartedly agree with James Cortada's comments from "Think Piece," ( IEEE Annals, vol. 23, no. 2, 2001, p. 88). In this article, he spoke about the need to adjust and open the focus on the history of information technology and, accordingly, the contents of the Annals on such things as how computers were used. Additionally, I believe that we should study the motivation and expectation of decision makers in industry to invest large amounts of money into buying computers and then use them to help run their businesses.
However, we have to prepare ourselves for disappointment when we undertake such historic research and studies, as I discovered in my own research during the last two years. When I started to prepare for early retirement in the summer of 2001, after 32 years in computers and 20 years with a major bank in Switzerland, I became interested in how computing began in large Swiss banks and what the expectations and motivations of their decision makers were at the time they started to invest in these new electronic monsters. Thanks to my contacts in Swiss banking, I was allowed access to the historic archives of the two largest Swiss banks. I was then able to ask for documents from the 1950s and 1960s, when these banks were aggressively attempting to automate and incorporate computers into their daily functions.
I found to my disappointment that both archives did not contain any files, memoranda, or minutes of meetings concerning business processes and computers. Unfortunately I was not allowed to personally search the archives due to legal restrictions. I was told by the archives' librarians that decisions were taken informally at that time, often without written documentation, and that no historic value was attached to whatever documents existed. The only documents that still existed were formal publications such as staff newsletters and customer information publications. Most of the key decision makers of the time have passed away in the meantime and the few survivors were too young at the time to have been involved in the decision making. While existing material and the memories of a few technicians allowed me to document which computers were used and how they were used, I can only speculate about motivation and expectations of the persons who decided to invest into the new technology of computers. What research I did find is being published in this issue of Annals (see "Early Use of Computers in Swiss Banks," vol. 26, no. 3, pp. 50-59).
Hans Neukom; email@example.com
In Michael Mahoney's article, "Finding a History for Software Engineering," ( IEEE Annals, vol. 26, no. 1, 2004, pp. 8-19), Mahoney begins the article by stating the following:
Dating from the first international conference on the topic in October 1968, software engineering just turned 35. It has all the hallmarks of an established discipline: societies (or subsocieties), journals, textbooks and curricula, even research institutes.
I disagreed strongly with Mahoney's use of the word "all" in the second sentence of this article. However, from then on, I found the article interesting and worth the time required to read and think about its contents and their implications. Some of the author's deductions I found insightful and of potential but generally overlooked consequence.
I'd like to explain why I disagree with his use of the word "all." The field of software engineering does not have all the hallmarks of an established discipline. It has many, perhaps even most, but it lacks particularly important ones—such as a consensus on a core body of knowledge required of its practitioners and the regular, systematic, and consequent application of mathematical and scientific models as a basis for daily practical work.
As an electrical engineer by education who has worked extensively in computing and software for many years, I strongly believe that software development is by nature an engineering discipline and that it should, also in practice, become one. I see many similarities between software development and the traditional engineering disciplines.
I usually relieve my frustration about the slowness of our metamorphosis to an engineering discipline by observing that the now traditional engineering fields also took a long time to become true engineering disciplines. On page 10, Mahoney pointed to a reason for our slowness: "No one mathematical model had proved adequate to the diversity of computing, and the different models were not related in any effective way." This derives from the fact that the traditional engineering fields' working environment—the physical world—is not of human making, while the software developers' working environment is of our making, and we have not yet finished deciding what we are making. I suppose that given this, it is not surprising that our rate of progress to a state of true engineering is slow.
In addition to the physical versus human-made environment, several other differences exist between software development and traditional engineering fields. For example, compare the differences between two phases of typical engineering disciplines with software engineering: design on the one hand and construction, building, production, reproducing, and manufacturing on the other hand.
In the design phase, most traditional engineers produce documents stating what materials to combine to create the desired artifact. In the construction phase, nonengineers perform the tasks to create the artifact, often under the supervision of engineers. In the traditional engineering disciplines, most of the costs are incurred in the construction phase—mainly because of the quantities of materials and material handling needed. In software development, usually the reverse is true: the costs incurred in the design phase normally exceed the comparatively low costs of reproducing a number of copies of the software and its documentation. As outlined in Mahoney's article, Taylor's and other industrial engineering efforts were directed at the repetitive activities involved in production, not the design work.
It is not surprising that solutions to the problems of artifact production from traditional engineering fields do not directly transfer to software development. The design phase for software development is characterized by relatively one-off tasks, each one of which differs from the others in some way and none of which is repeated exactly. Productivity lies in intellectual creativity applied to the nonrepetitive tasks.
The production phase, on the other hand, is characterized by tasks that are repeated many times. Productivity here relies on efficient, mechanistic organization for performing the tasks repetitively. Extenuating the situation is Mahoney's correct observation that many software development problems occur earlier, when determining the external specification of the software system to be designed and implemented. He rightly points out on p. 17 that this activity "is not about software, indeed … it may not be about engineering at all." We all know about too many systems conceived by software specialists and subsequently rejected by the intended customers.
Mahoney presents the levels of modeling in software development in Figure 1 (p. 16). Figure 1 represents, it seems to me, a confused and unclear division of phases in the conception, design, and implementation of an engineering artifact. As Mahoney points out, developers are on firmer ground in the lower third of the figure, and the causes of problems typically arise in the upper parts. More typical of the development and construction of engineering artifacts are, in my view and experience, three phases:
In software terms, the second phase (design) ends with the program and its documentation. The third phase ends with the desired number of copies of the program and its documentation, either installed on the customer's sites or in a form for distribution to the customer.
Figure 1 may be an accurate representation of software development as practiced by some, but not all, software developers. If so, the confusion and vagueness in parts of it explain some of the reasons for the problems that often arise (as Mahoney mentions in the article).
Mahoney's suggestion that software development (at least part of it) might be more related to architecture than engineering, along with his observation that we educate architects differently than engineers, is interesting and deserves more thought from software engineering educators. Successful software projects are often characterized by close involvement of people with expertise and experience in the application domain.
Sometimes I think that years ago we missed a window of opportunity to undergo a transition to a true engineering field. The field grew so fast that many people were drawn into software development who lacked the balance between theory and practice, which is critical for engineering. As a result, we have many theoretically oriented and many more practically oriented people in the field. Few, however, exhibit the balance identified by Vitruvius some 2,000 years ago when he was the civilized world's chief architect. In his retirement, he wrote a 10-volume account of all known technology, encompassing not only city planning, building materials, and acoustics, but also information about timekeeping (water clocks and sundials), various pumps, contract law, astronomy, the arts, and medicine.
Because so few people in the software field exhibit a Vitruvian balance between theory and practice, we're incapable of making the transition to a true engineering discipline or—worse still—educating the next generation to introduce the metamorphosis. As a society, we'll probably have to wait for some new major shift, crisis, or catastrophe to occur before the next window of opportunity appears.
Robert L. Baber, University of Limerick; firstname.lastname@example.org
In an "Anecdotes" article by Joe Rogers ( IEEE Annals, vol. 26, no. 1, 2004, pp. 59-65), he inadvertently described the core memory for the IBM 1401 as operating in a mechanical fashion. In fact, the 1401 memory relied on the orientation of the magnetic field in the core as described in Emerson Pugh's book, Memories that Shaped an Industry (MIT Press, 1984).
Michael R. Williams, Computer History Museum; email@example.com