3. Software Engineering
Part of
CS:2820 Object Oriented Software Development Notes, Spring 2021
|
The term software engineering has frequently been used for what this course introduces, but this term is simultaneously falling on hard times in some circles while it becomes deeply entrenched in others.
Knowing something of the history of software engineering helps understand the conflict here. As software systems grew in the 1960's and 1970's, people looking at the economics of software noticed something disturbing: While the price of hardware was falling, following Moore's Law, the cost of software was soaring. This came to be known as the "software crisis" and it never ended. There were huge software boondoggles in both government and private industry. F. P. Brooks' classic book The Mythical Man Month (1975, Addison-Wesley, and still in print) documented the problem and proposed some solutions.
Many observers of this situation found the contrast between the productivity of hardware engineering and the crisis with software development asked: "Why can't software development be done as an engineering discipline." This led naturally to the term "software engineering" as a buzzword for how software ought to be developed.
The negative assessment of software engineering rests on two observations: First, many of the early proponents of software engineering seem to have had romantic misunderstandings of the nature of engineering. If you ask the designers of a bridge across a large river what they are doing, they will typically describe the initial stages of the design as being high art. After making an artistic selection of a particular approach to building a bridge, perhaps a cable-stayed bridge, for example, a typical civil engineer would say, "and then the real engineering begins, deciding how much rebar to put where, how many bolts go in this joint, how many cable stays, and how thick is the cable?" The work the civil engineer describes as "real engineering" is comparable to the detail work in computing that people sometimes call "coding".
Meanwhile, the work that proponents of software engineering want to call engineering and want to systematize seems comparable to the high level design work that civil engineers might refer to as being a high art.
Between 1950 when the first computers were just being introduced until the mid 1970s, many in management though that programming was basically clerical. Programmers sit around and use devices that resemble typewriters and their "work product" is just text. How is that different from a clerical worker? Therefore, of course, programmers were frequently paid like clerical workers. The industrial response to the emergence of the term "software engineering" was the immediate promotion of this term to a job title. This allowed parallel pay and promotion structures programmers and conventional engineers without offending personnell managers.
Sexism in computer science: Back when programming was seen as clerical work, many women were hired as programmers. After all, it was just clerical work, and women were seen as well suited to such jobs. If you look at the staffing of early computer labs between 1945 and 1955, there were electrical engineers building the computers, typically all men, mathematicians devising algorithms to run on the machines, typically all men, and a staff of clerical workers, typically all women, who did the actual programming. Generally, the engineers and mathematicians got all the credit.
In this environment, it is not surprising that many of the early leaders in computer science were women. Grace Murray Hopper ended up rising from "coding clerk" to the head of software for the US Navy and also the first woman admiral in the navy. My coauthor Barbara Simons became president of the ACM. My first boss in my first paid programming job back in 1972 was a Black woman.
Starting in the 1970s around the same time as the term software engineering came into use, the fraction of women engaged in computer science began to fall. Some blame this fall on the fact that, as managers and personnell departments began to understand that programming was not a clerical job and that it really does resemble engineering, they began to apply their prejudices about engineering to their hiring practices. "If it's a kind of engineering, we should hire men, because men are better suited to engineering."
This is probably only part of the picture. Personal computers began to emerge in the 1970s. At first, they were kits, aimed at people who wanted to build their own computer from parts. The market was small and focused on people who tinkered with hardware, mostly young men. Then the Apple ][ came on the market and not long after, the IBM PC. Marketing programs and advertising quickly began to shape the perception of who should be interested in computing. If you look at the first mass-market advertising for computers, you find that it is targeted at parents of teen-aged boys: "You need to buy your son a computer so he can be prepared to enter the high-tech workforce of the future."
Now, almost 50 years after the emergence of software engineering, there are skeptics in both the academic and industrial world who consider software engineering to be, at best "computer science lite" (to quote one former department chair).
Meanwhile the study of software engineering has produced insights into the management of large projects. Some things that sound like buzzwords that have come from software engineering are actually valueable. "Extreme programming" is an example. While slavish adherence to the XP methodology may be silly, the underlying ideas of incremental development are very powerful. UML, as a formal graphical language for describing programs may be foolish, but selective informal use of the notation is frequently useful during the early stages of a software project.
The idea of object-oriented programming was born in two different domains, independently and around the same time in the mid 1960s:
Viewing the world this way is a gross oversimplificaiton, but nonetheless, discrete event models have proven to be extremely applicable to areas as far apart as digital logic and logistics. The problem with discrete event models is that there are a huge number of different classes of events and classes of objects in a typical model. Making sense of these was a problem.
Consider a traffic simulation model: The primary classes are roads, vehicles and intersections. Vehicles come in many subclasses, cars, trucks and vans, for example, with trucks subdivided into semi-trailer trucks and simple trucks.
Again, as operating systems grow, the number of different classes of resources grows. You have disk files, network streams, timers, processes, memory segments, and more. There are multiple classes of disk devices, multiple classes of files, and more. Making sense of these was a problem.
A group of programmers working in Oslo, Norway developed the idea of objects, classes, class hierarchy and almost all of the other key concepts of object-oriented programming in the mid 1960's. They came at this from thinking about discrete event simulations, mostly as applied to logistics. If you are moving materials from here to there, you have trucks to move things, but there are different classes of trucks each with different attributes. Semi trucks and pickup trucks are both types of trucks, but you can detatch the trailer from a semi, while you cannot detatch the cargo area of a pickup (ignoring the possible use of a chainsaw on a modern aluminum truck).
This group, led by O.J. Dahl, developed a simulation language called Simula while they were working this out, and as they finally came to understand the consequences of their ideas, they created a distinctly new language called Simula 67 (the target release date was 1967, but since this is software, they were late).
Simula 67 was not a simulation language, it was a completely general purpose object-oriented programming language, the very first of its kind. We get essentially all of our standard terms for object-oriented programming from Simula 67. Some people have gone so far as to describe Simula 67 as an improvement over most of its successors (that includes C++ and Java).
The other important group in this story was a group led by Christopher Strachey at Cambridge University in England. Strachey was as much a theorist as a practical programmer. His group designed a programming language called CPL (there is disagreement about whether the C stood for Christopher's or Cambridge or Combined, but PL stood for Programming Language). Nobody ever succeeded in implementing CPL, but a student implemented a subset called BCPL (Basic CPL).
One of the things that Strachey's group explored was the use of BCPL as an operating system development language. It is important to know that BCPL was not object oriented in any way. It was very primitive, but unlike other languages of the era (with the exception of assembly language), it allowed people to invent just about any kind of programming model they wanted. As Strachey and his associate Joseph Stoy developed a toy operating system called OS6, they discovered the basic ideas of objects, applying them primarily to I/O streams, where all kinds of I/O were implemented essentially as subclasses of a common stream interface class. They did not have object-oriented terminology, but they had the idea.
BCPL attracted attention at MIT in the mid to late 1960s, particularly in the group centered there building a new computer system called MULTICS (The Multiplexed Information and Computing Service). MULTICS was designed to be a computer utility, with the idea that people could buy computing service just the same way they buy electric power and telephone service. Conceptually, MULTICS is the ancestor of what we now call ISPs and cloud computing providers. The MULTICS project also involved General Electric and Bell Telephone Laboratories, Bell Labs for short.
After Bell Labs pulled out of the MULTICS project, a small group there decided to build a scaled-down system informed by their experience with MULTICS. They called it Unix. They were quite interested in BCPL, and one of them, Ken Thompson, designed a new simplified version of BCPL that he named, simply, B. The B project and the first version of UNIX were married when Brian Kernighan and Dennis Ritchie extended B to support a limited concept of data types. They called this new language C and used it to rewrite UNIX in the early 1970s. The internals of Unix, particularly, those involved with input/output, have a strong object-oriented flavor despite the fact that there is no support for objects in C.
When Bjarne Stroustrup, an experienced Simula 67 programmer from Denmark, was hired by the Unix group at Bell Labs, he was sufficiently annoyed by the lack of support for objects in C that he wrote a C preprocessor that he called C++ that extended C with the features of Simula 67 that he liked. A preprocessor for a programming language takes input in an extended version of that language and produces output in that language. The original C++ preprocessor translated C++ to C. Only after versions of C++ were written outside of Bell Labs was a true C++ compiler written.
By 1980, C++ began its spread outside of Bell Labs and the Unix world. Two things contributed to this: One was BSD Unix, the first version of Unix supported on the then best-selling 32-bit mainframe of the era, the VAX 11/780 made by Digital Equipment Corporation. We bought one here at the University of Iowa, and we ran Unix on it; the story was very similar in universities around the world. The second thing was the GNU C++ compiler, the most important of the early ventures in open-source software development.
At Sun Microsystems in the early 1990s, James Gosling was not happy with the C foundation of C++ and set out to strip away the mistakes that C++ had inherited from C and produce a lightweight language called Java. This had two main selling points: First, it looked like C++ so programmers who knew that language could move to Java with minimal "culture shock." Second, many of the dangerous features of C were disabled. Some early wags described Java as being C++ with training wheels.
Why cover all this history? Not because you will need it, but it drives home the fact that programming languages are not products of nature but rather, products of human ingenuity and invention. As such, they are as worthy of criticism as any work or art or literature.