1960 to 1969: Exodus

Security and Cryptography Security Software Engineering Internet/Online Mike Andrews James A. Whittaker Addison-Wesley Professional How to Break Web Software: Functional and Security Testing of Web Applications and Web Services 1960 to 1969: Exodus By the late 1950s, computers had become quite a phenomenon, and at the dawn of the 1960s, the discipline of software development went public. Universities began offering degree programs in this new technology, and the number of hardware manufacturers grew rapidly. Suddenly, computer hardware and training were accessible to the general public—or at least to the subset that attended college. At the same time, computers were undergoing big advances in usability and capability. The problems they could solve grew in scope and complexity. The programming languages designed to solve those problems were also becoming more powerful and easier to apply. The 1960s were a phenomenal growth period for computing technology and set the tone for the remainder of the century. The 1960s also offered the industry's first chance to go astray. Less rigorous minds were tackling harder problems. (Indeed, how could the industry have found more rigorous, meticulous developers than it had in the 1950s?) This was the perfect recipe for disaster—but the disaster never happened. Software written during the 1960s attained the same high quality as programs written in the previous decade. This seeming paradox has a simple, though unobvious, explanation: The factor that kept programmers honest and program quality high in the 1960s was the unavailability of personal compilers. Compilation in the 1960s was not an easy endeavor. For the most part, a company or university owned only a single, huge computer. This computer's compiler was, first, located a long walk from the programmer's office; second, so heavily booked that access required advance reservations; and, third, painfully unsympathetic to misuses of programming language syntax and constructs. In other words, compiling a program that wasn't near perfect was a significant waste of time and effort, and it could lead to substantial rework. Imagine walking a half mile across campus with a nine-inch stack of punched cards only to have the stack of cards rejected by a "type mismatch" error on card 30. This could result in days, even weeks, of delay before another session with the sole compiler became available. This painful compilation process kept programmers at their office desks—checking, soliciting peer review, and reading, reading, reading their cards (the code) until they had exhausted every available avenue of review. No measures were too extreme, because the price for sloppiness was severe. So, in the 1960s, as complexity grew and less rigorous-minded people tackled the problems, the discipline of software development had leaped its first serious hurdle—software's debut to the wider public was a success.