Cargo-cult Engineering

There is an old song about software engineering. I thought it had died until the other day I came across a post by Jack Ganssle (Embedded.com; 05/12/08). Under the title “Programmer or Engineer?” he argues that the word “programmer” should be banned and that embedded applications should by built by electrical or computer engineers.

It may well be that engineers are satisfactory for the “embedded applications” that Mr Ganssle has in mind. But another category of people is needed to meet the greater challenges posed by computers. Neither of the existing categories: “engineer” nor “computer scientist” can be relied on to fit the bill.

The existing categories are not suitable

The unsuitability of computer scientists is charmingly documented by the late Alan Perlis:


I think that it’s extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don’t think we are. I think we’re responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope we don’t become missionaries. Don’t feel as if you’re Bible salesmen. The world has too many of these already. What you know about computing other people will learn. Don’t feel as if the key to successful computing is only in your hands. What’s in your hands, I think and hope is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more.

My belief that engineers don’t do any better, though for different reasons, is based on observations of a few of my friends who have transcended the distinction between engineer and computer scientist.

A proposal by Parnas

Ganssle proposed to qualify only electrical or computer engineers for the programming of embedded systems. Things were not so simple for David Parnas, who pondered the unsuitability of computer scientists a long time ago. He was under no illusions about the suitability of those designated “electrical engineer” or “computer engineer”. Accordingly he advocated a new branch of engineering.

Parnas’s proposal was embraced in many quarters because it responded to the overwhelming feeling that something urgently needed to be done. Yet the situation may not be as clear-cut as Parnas presents it. He pointed out that today’s students’ careers could last four decades and stated:


“We must identify the fundamentals that will be valid and useful over that period and emphasize those principles in the lectures.”

We must, we must, for sure. But can we?

Apparently, the idea is that it is better to have fundamentals of something than no fundamentals. In fact we need capable and responsible programmers. What is proposed is a curriculum that differs from computer science by, for example, dropping courses on compilers and operating systems, and, for example, including General Chemistry for Engineers and Introduction to the Structure and Properties of Engineering Materials. The latter presumably have the virtue of Fundamentality, a unary property that makes it improper to ask: Fundamental to what?

Engineering from craft to profession

To see what is wrong with Parnas’s proposal, it helps to review the history of engineering. A brief and enlightening account can be found in John Allen’s paper “Whither Software Engineering?”, to be published soon.

We take it for granted that the established branches of engineering, Civil, Mechanical, Chemical, and Electrical, are based on science: physics and chemistry, and that these rely on nontrivial mathematics, mainly calculus. These are Fundamentals for the established branches of engineering. Hence the (now) established practice of having calculus and science courses as a prominent part in the first year of engineering programs.

However, this has not always been the case: it is the result of a long transition in engineering from shop culture to school culture. The transition began in France in the 18th century, spread to Germany in the early 19th, and to England and the US in the late 19th century.

In the early 19th century it was appropriate to call the builders of the early steam engines “engineers”, even though their work was not based on science. Thermodynamics was not just less developed than it is now: it did not exist. Engineering was in the stage that Allen calls “shop culture”.

Fast forward to software development in the year 2008: the underlying science does not exist; software development is in the craft stage. A possible transition into the professional stage is still in the future, if anywhere.

Thus the very term software engineering is misleading. It is OK to consider the practitioners of two centuries ago as engineers because all engineering was in the craft stage. But now that engineering is based on science, the very term “engineering” implies a discipline of that level. It is not OK to consider graduates of the proposed Parnas curriculum as engineers. They may have taken courses labelled as Fundamental, but they are not fundamental to software development. Or they may have been trained as electrical engineers, just as they may happen to have been trained as computer scientists or physicists. But as software developers they necessarily are craftsmen because a scientific basis for software development is lacking.

Cargo cult science

Parnas’s proposal reminds of the late Richard Feynman’s CalTech 1974 commencement address. Feynman explains why, even though they perfectly emulate science, certain studies in psychology are not. All the right moves are there: Null Hypotheses, Type I and Type II errors,…, the works. But though the form of these studies is perfect, the exercise is vacuous. He called this Cargo Cult Science, after the phenomenon observed shortly after the second world war on some of the islands in the Pacific. From Feynman’s address:

During the war they saw airplanes land with lots of good materials, and they want the same thing to happen now. So they’ve arranged to make things like runways, to put fires along the sides of the runways, to make a wooden hut for a man to sit in, with two wooden pieces on his head like headphones and bars of bamboo sticking out like antennas — he’s the controller — and they wait for the airplanes to land. They’re doing everything right. The form is perfect. It looks exactly the way it looked before. But it doesn’t work. No planes land.

We are in a similar situation. Over there’s the Paradise of Engineering. Whether it’s Civil, Mechanical, Chemical, Electrical, by and large those engineers are successful in delivering safe and satisfactory installations and products on time and within budget. Over here we are in software land where the most egregious failures and cost overruns are of the order of the day. Of course we want the same successes to happen Over Here. So we arrange everything just like it is Over There. Get every little detail right, the General Chemistry for Engineers and the Introduction to the Structure and Properties of Engineering Materials, the works. We have no idea how, but somehow the power of sympathetic magic will deliver the same successes Over Here.

Parnas’s proposal for a new engineering discipline, as the latest member in the sequence of civil, mechanical, mining, and electrical engineering, was an exercise in cargo cult engineering.

A new category is needed

The prime example of the type that we very much need is the late Edsger Dijkstra. He performed engineering feats of the highest order that no engineer, nor anybody else, had achieved: the lowel-level I/O software for the Electrologica X-1 computer, the first compiler for Algol 60, and the THE operating system.

Dijkstra was conscious of being of a new breed, and he chose “programmer” for its name. He considered programming as a discipline that required the highest intellectual level. This claim has to be taken seriously from someone who was educated as a theoretical physicistat a good university.

Compare this with the sense that Mr Ganssle assigns to the word “programmer”:

A programmer is one who writes programs. That’s subtly like “coder,” a person who cranks code out all day. Coders, like technicians and janitors are vitally needed employees. But they can be devastating to software projects.

For Mr Ganssle the remedy is simple, just avoid “programmers” and make sure you hire certified engineers:

Most of us are engineers: software engineers, firmware engineers, or hardware/software engineers, no matter what degree we earned. In fact, in a recent Embedded poll only 13% of respondents claimed only a computer science degree; 80% have a sheepskin with an engineering title (EE or CE).

Parnas’s proposal revisited

Logic compels me to conclude that software development, being in the craft stage, should be taught according to the guild system. But, being a university man, I like to believe that these institutions have something to contribute.

Does this mean that computer science departments can supply the programmers we need? No, there faculty are hired and maintained on the basis of scholarly publications. A great programmer would not be accepted as such on the faculty. Dijkstra was welcomed in a Computer Science department as a celebrity computer person, not as a computer scientist.

Does this mean that universities cannot help in fostering programmers? Not at all. Some departments have suitably different standards: they welcome to their faculty performers rather than generators of publications in refereed scholarly journals. Departments of Music are an example.

There is another way in which universities can help. In the 1950s the first programmers were recruited on no other basis than being a promising oddball. One of the prerequisites for being counted in this category was a nontrivial college degree (Mark Halpern — English literature, Edsger Dijkstra — theoretical physics, Tony Hoare — classics). This in itself ensured, though perhaps not exceptional intelligence, at least not a debilitating lack of it. But in these particular cases, exceptional talent was recruited. So this is something that universities can do as help toward great programmers: organize demanding programs wherever they can, independently of computers or programming.

Of course we can be less hit-and-miss than this, now that we at least have the concept of “programmer”, even when we do not have a clear idea of how to help to bring them into being. For example, Ars Digita University, which existed from 2000 to 2001, taught a ten-month course in programming (not “software development”, nor “software engineering”) to graduates with solid college degrees, ideally without exposure to computer science or software development. In each of the ten months of the course, students studied one of ten books (typical representatives: Abelson and Sussman, Patterson and Hennessey, Cormen/Rivest/Leiserson). There was lots of lab work. It was an intensive course.

2 Responses to “Cargo-cult Engineering”

  1. Michael Says:

    Now that I have made the apparently succesful transition from “scientist” to “programmer”, I am struck by a number of things about the products we (at Apple) produce. Your interesting article brought some of these to mind.

    Most of the software that I have been involved with here works almost all the time, is used (a lot) by many people, and improves the quality of their lives, at least from there own perspective. The characteristic of this software that distinguishes it from Dijkstra’s products is that the software is created, enhanced and maintained by teams of people. Some of them write lines of code, while others maintain wikis, manage bug-tracking databases, run tests, design interfaces and so on. Certainly that subset who actually churn out lines of C needed a lot of training. The courses we taught as part of our undergradaute program were fine for this training. On the other hand, I would say that the grades we gave were a very poor predictor of programmer quality. The only exception is that those few people who consistently attained As in evry course they ever took were likely to be successful programmers.

    But there is a lot more to a successful software product than lines of code. And I see little evidence that these factors can be taught at a University or any other institute. Rather, they are a pool of much individual experience and talent.

  2. Kevin Hely Says:

    I couldn’t agree more. It’s about time someone said this. Thank you.

    Parenthetically, I might add that, when I took undergrad courses on compiler design and operating system design, it was quite clear that the main topic of study was “techniques for the systematic design of non-trivial software artefacts”. The specific applications were merely example “carriers” for technique, like √©tudes for music students. I find it hard to see how to transmit this ability to students without using detailed specific examples. (However, this was in the mid-eighties… evidently things have changed in CS education since then.)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: