Читать книгу Code Nation - Michael J. Halvorson - Страница 18

In October 1968, there was a sense of crisis in the air.

Although this year has been described as one of the most turbulent in the 20^th century, the turning point was not related to political or military disruptions, but to a crisis in the nascent field of software engineering. In fact, executives in North America and Europe had been sounding the alarm since the mid-1960s. Now that powerful mainframe computers were transforming the world’s business and engineering systems, the software that drove these machines was taking on an oversized role in public life. Just weeks before Richard Nixon, Hubert Humphrey, and George Wallace faced off in the 1968 American Presidential Election, the world’s engineers were worrying about computers and software. Computing mythologiesNATO Conference on Software Engineering

To list a few of the problems, there was a perpetual shortage of programmers to create software for the new systems. These programs were often massive, stretching to tens of thousands—even millions—of lines of code in computer languages like COBOL COBOL, Formula translation (FORTRAN) FORTRAN, and Algorithmic Language (ALGOL) ALGOL. The code configured American military systems and corporate data processing tools—programs like the banking, billing, and reservation systems that proliferated in the late 1960s. However, good software developers were hard to find. There was no clear procedure for locating, hiring, and training the specialists needed to build and maintain the required systems.

The growing complexity of software also required robust management techniques to ensure that projects were completed on time and on budget, but neither outcome was very common. To make matters worse, the growth of professional organizations like the Association for Computing Machinery (ACM) Association for Computing Machinery (ACM) found it difficult to improve programmer productivity or software quality. Although revenue was pouring in to successful American hardware manufacturers like IBM, Burroughs, and Digital Equipment Corporation (DEC) Digital Equipment Corporation (DEC), the budding software industry seemed undisciplined in its workflows, ill-prepared to expand, and in a perpetual state of disorder.

Much has been written about the Softwarecrisis “software crisis” of the late 1960s, and some have argued that Software engineering “software engineering” was the wrong metaphor to address the problems.³ But the dilemma was noted by many computer professionals around the world, from North America to Asia to Europe. The 1960s was a time of expansion, as organizations were drawn to utopian visions of mainframe and minicomputer technologies. But reassessments soon followed, and critics pointed to bloated software systems that were complex and error prone; programs designed for engineers with pocket protectors but not real people. The job performance of corporate software developers also came under fire. “When a computer programmer is good, he is very, very good,” concluded one IBM study published in 1968. “But when he is bad, he is horrid.”⁴Computing mythologiesNATO Conference on Software Engineering

Figure 2.1IBM Executives face the camera in front of a bank of IBM 729 magnetic tape drives, 1962. (Photo by The LIFE Picture Collection via Getty Images/Getty Images)

The gender implications embedded in this statement are subtle, but important to catch. In 1968, approximately 88% of professional programmers in the U.S. were men. Although women made significant contributions to computing in the 1950s, programming work underwent a process of Masculinization masculinization in Britain and America in the 1960s and 1970s.⁵ As part of this transition, the cultural stereotypes about programming being a male activity increased, and the era’s sources often associate programming with masculinity. The implications of the underrepresentation of women in computing will be examined in Chapters 3, 7, 8, and 10, which explore how Americans learned to code, and how new programmers negotiated for status in the communities that either welcomed or rejected them. Keep an eye on this complex issue; it surfaces in predictable but also unlikely settings. (See Figure 2.1.)

To address the global software crisis, the Science Committee of NATO Science Committee of NATO sponsored a conference in October 1968, in the Garmisch-Partenkirchen district of West Computing mythologiesNATO Conference on Software Engineering Germany (Bavaria). The organizers planned to discuss the design and production of computer software, the experiences of software users, and the persistent problem of meeting software schedules and budgets. The term Software engineering “Software Engineering” was chosen as a framing title for the meetings, hinting at a proposed solution to the dilemma: The computer industry should infuse programming with theory and practice from the disciplines of science and engineering to address their problems. It was high time to demand structured approaches to design, coding practices, and testing that would improve reliability. If this did not happen soon, the complexity of software, and its concomitant unpredictability, would likely stifle the electronic computer revolution.

The 5-day conference was attended by 50 people from 11 countries, with a large contingent representing the U.S. All 50 registered conference participants were men, with a few women serving in support roles. Analyzing the conference materials, Janet Abbate sees the absence of the American Hopper, Grace Murray Grace Murray Hopper as the most striking in terms of gender exclusion. In 1968, Hopper served as the director of programming languages and standards for the U.S. Navy, and she was an established luminary in the computing industry.⁶

The proceedings show that the attendees were mostly computing professionals who managed software teams or worked regularly with the users of software systems. There were manufacturers’ representatives in attendance, as well as academics speaking for interested university faculties.⁷ As Nathan Ensmenger wrote, the meeting marked a major shift in general perceptions about software construction.⁸ After Garmisch, there was pressure on software developers to eschew craft and artisan approaches to programming and to adopt established engineering principles. The wild and woolly days of coding by trial and error were over. (Or so the organizers hoped.) Although some came to question the value of software engineering as a framing term, the methodology would have an important impact on programming culture in the coming decades.⁹Computing mythologiesNATO Conference on Software Engineering

Let’s take a look at the problems software developers wrestled with in the 1960s. At that time, the dominant paradigm for software development revolved around a solitary (male) computer genius enigmatically holding court with a small team of assistants. The consensus at Garmisch was that this scenario needed to be replaced with a cohort of systematically-trained engineers, responsible to management, who practiced structural thinking and followed orders. (A visual model of this hierarchy and approach can be seen in Figure 2.2.) As Nathan Ensmenger summarized, “Software engineering promised to bring control and predictability to the traditionally undisciplined practices of software development.”¹⁰

Historian Stuart Shapiro analyzed the legacy of this Engineering movement “engineering movement” as it gained momentum in the 1970s and 1980s. According to Shapiro, the program was less about specific technical procedures and more about finding ways to regulate and standardize growing project complexity, budgets, and the new cadre of software engineers who had until recently attracted little notice. New approaches to programming took center stage in the push to make software development outcomes more reliable. These strategies included the use of Structured programming structured programming techniques, adding language features to promote reliability, measuring software performance (metrics), and using IDEs.Integrated development environments (IDEs) Integrated development environments (IDEs) integrated development environments (IDEs).¹¹ Most of these ideas would make their way into personal computing, too, although it would take a decade or more for the engineering practices to take hold.

Computer programming is sometimes envisioned as an individual task, but by the late 1960s, commercial software was typically constructed in groups. For example, in mainframe computing environments like the IBM IBMSystem/360 System/360, it was necessary to hire an army of analysts, technicians, and software developers to build and maintain non-trivial systems. Productivity gains associated with the “Division of labor” principle “division of labor” principle simply did not work when dividing up the tasks of a large software project. The new approach had to involve teaming. Grace Hopper subtly introduced this concept when she created the world’s first computer language compiler in 1952, known as the A-0 compiler A-0 system, which translated symbolic codes into Machine language machine language. Hopper completed the first draft of her work and then immediately shared it with associates to see if they could make improvements, a strategy that she also followed during the creation of FLOW-MATIC FLOW-MATIC, the predecessor to COBOL. Computing mythologiesNATO Conference on Software Engineering

Figure 2.2By the 1960s, many engineering groups were using structure and clearly defined roles to bring predictability to their projects. The team that created the DEC PDP-6 computer was led by C. Gordon Bell, the man wearing a suit jacket in this 1964 photo.

Standing L–R: Peter Sampson—Operating System Programmer, Leo Gossell—Diagnostic Software Programmer, C. Gordon Bell—PDP-6 System Designer (Creator), Alan Kotok—Operating System Lead, Russell Doane—Circuit Design Engineer, Bill Kellicker—Programmer, Bob Reed—Hardware Technician, George Vogelsang—Draftsman.

Sitting L–R: Lydia Lowe (McKalip)—Secretary to C. Gordon Bell, Bill Colburn—PDP-6 Project Engineer, Ken Senior—Field Service Technician, Ken Fitzgerald—Mechanical Engineer, Norman Hurst—Programmer, Harris Hyman, Operating Systems Programmer. (Courtesy the Computer History Museum and DEC)