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.
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.
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?
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.
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.
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 physicist at 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).
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.