Code Nation. Michael J. Halvorson

outputs that a program might encounter as it completed its work.

      Real-world computer systems

      Real-world computer systems were designed so that they used only a prescribed set of resources, such as memory and processor time. From the point of view of the programmer, additional complexity arrived in the selection of programming languages, data structures, Algorithms algorithms, flow control mechanisms, error handling structures, and the use of inherited source files and legacy code from other projects.

      Individual computer programmers also brought their own tastes and psychological experiences to a project, as well as diverse training and educational experiences. All of these variables made the precise functionality of programs hard to predict, in the same way that storms and atmospheric conditions are challenging to forecast. The intricate balancing act was magnified in myriad ways as the responsibility for building new systems was distributed among team members who had different abilities and often coded in different locations and contexts.

      In the late 1960s, anxious managers noted that the complexity of large systems created engineering problems with no easy solutions or mechanisms for assessment and control. As E.E. David of Bell Laboratories pointed out at the Garmisch conference,

      Production of large software has become a scare item for management. By reputation it is often an unprofitable morass, costly and unending. This reputation is perhaps deserved. No less a person than T. J. Watson [Jr., Chairman and CEO of IBM] said that OS/360 OS/360 cost IBM over 50 million dollars a year during its preparation, and at least 5000 man-years’ investment.¹³

      In David’s telling example, the software development project for OS/360 (IBM’s operating system for the 360 series of computers) was famously late and over budget, problems blamed on poor management practices and unwieldy development teams. The project became the subject of Brooks, Fred Frederick Brooks’s well-known guidebook on managing software projects, The Mythical Man-Month (1975), which we Computing mythologiescomplexity of software will return to when I analyze commercial programming cultures and integrated software suites in Chapter 11.

      

      Figure 2.3A panel session from the 1968 Conference on Software Engineering in Garmisch, West Germany. Addressing the group is M. D. (Doug) McIlroy. (Photo by Robert M. McClure and used with his permission)

2.3Computing mythologiessystems for customersSystems are Systemfor customers for Customers

      Who were these early software systems designed for, and what percentage of the population did they actually represent? Playing back conversations from the 1960s, it is sometimes hard to tell. Here is one fascinating transcript from the 1968 conference that we have been using as a touchstone. It involves six prominent leaders from the global computer industry, including two computer manufacturers, three academics, and one of the conference’s organizers.¹⁴ (See Figure 2.3.) The exchange focused on the users of computer software and the extent to which customersComputing mythologiessystems for customers Systemfor customers should be included in the design of new software —an emphasis which appears to be lacking in the first systems. A cautious professor J. N. P. Hume begins the dialog. (The italic is mine.)

      J. N. P. Hume [University of Toronto]: One must be careful to avoid over-reacting to individual users. It is impossible to keep all of the users happy. You must identify and then concentrate on the requirements common to a majority of users, even if this means driving a few users with special requirements away. Particularly in a university environment you take certain liberties with people’s freedom in order to have the majority happy. J. D. Babcock [Allen-Babcock ComputingAllen-Babcock Computing, New York, NY]: In our experience the users are very brilliant people, especially if they are your customers and depend on you for their livelihood. We find that every design phase we go through we base strictly on the users’ reactions to the previous system. The users are the people who do our design, once we get started. J. Berghuis [Dutch professor and industry consultant]: Users are interested in systems requirements and buy systems in that way. But that implies that they are able to say what they want. Most of the users aren’t able to. One of the greatest difficulties will be out of our field as soon as the users realize what kind of problems they have. J. W. Smith [Scientific Data Systems, El Segundo, CA]: Many of the people who design software refer to users as ‘they’, ‘them’. They are some odd breed of cats living there in the outer world, knowing nothing, to whom nothing is owed. Most of the designers of manufacturers’ software are designing, I think, for their own benefit — they are literally playing games. They have no conception of validating their design before sending it out, or even evaluating the design in the light of potential use. The real problem is training the people to do the design. Most designers of software are damn well incompetent, one way or another. M. Paul [Leibniz-Rechenzentrum, Munich]: The customer often does not know what he needs, and is sometimes cut off from knowing what is or what might be available. Perlis, AlanAlan Perlis [Conference organizer, Carnegie Mellon University, Pittsburgh, PA]: Almost all users require much less from a large operating system than is provided.

      Computing mythologiessystems for customers

      Systemfor customers

      Imagine a heated conversation among influential professors and experts who think that they each know best, and you’ve got the gist of this exchange. But notice how divided the industry leaders are about computer users and the design of software in the 1960s. Each person is wondering: who are these systems really designed for? How much functionality should be provided to users?

      Professor Hume outlined a realist position: You cannot make all of the software users happy, but if you try to satisfy a majority of them, you will probably find a good balance. Hume believed that it was legitimate to take away the freedoms of users on occasion to protect the system or satisfy the needs of the majority. We are still wrestling with the implications of this statement for security and civil liberties in electronic environments.

      Bristling at the regimenting tone of this statement, James Babcock of Allen-Babcock Computing Allen-Babcock Computing rushed to the defense of software users, whom he styled as “brilliant.”

      Allen-Babcock Computing was founded in 1964 in Los Angeles by James Babcock and Michael Jane Allen Babcock to profit from the rapidly expanding market for computer time-sharing services. Between 1965 and 1966, the company participated in the development of CPS.Conversational Programming System (CPS) Conversational Programming System (CPS) Conversational Programming System (CPS), a time-sharing product that ran under IBM’s popular OS/360 OS/360. In 1969, Allen-Babcock held a 3% share of the time-sharing services market—a lucrative position in this developing field.¹⁵ Babcock’s direct experience with “external” computer users like this is unusual but important to catch. He had regular contact with paying customers in a competitive marketplace outside of academic or corporate contexts, where “control” over the system typically trumped the preferences of users. In Babcock’s opinion, if computer users do not directly enjoy the benefits of a new system, it is of little value.

      But can computer users really be trusted? Professor Berghuis replied to Babcock that in his opinion customers had the right to make their selections, but most users do not know how to do it. If they only knew what computers were capable of, Berghuis mused, then software construction would be so much easier. Here, Berghuis puts the burden on users to know what they need, rather than on software designers to assess a customer’s requirements.

      J. W. Smith of SDS.Scientific Data Systems (SDS) Scientific Data Systems (SDS) Scientific Data Systems (SDS), El Segunda, California, supported James Babcock’s position and he also spoke as an advocate for users. Computing mythologiessystems for customers Systemfor customers

      SDS Scientific Data Systems (SDS) was a computer company established in 1961 by Max Palevsky and Robert Beck, veterans of the engineering firms Packard Bell and Bendix. This firm was an early adopter