to a talk last year, the high-profile stories receiving the most media attention included the break-in to vice presidential candidate Sarah Palin’s email account and the successful hacking of the Large Hadron Collider Web site. Recently, one of my credit card companies reissued a card to me because a third-party database had been hacked (the credit card company would not identify the database).
I often encounter CS faculty members who take it for granted that all large computer systems are full of bugs and unreliable, and of course our experience with popular software such as Microsoft Windows reinforces this notion. The very use of the word “virus” is annoyingly misleading because it implies that really such infections are expected and impossible to eliminate, when in fact it is perfectly possible to design reliable operating systems that are immune to casual attacks. Early in the history of eBay, its auction software failed for nearly a week, and the company lost billions of dollars in capitalization. At the time I wrote to the founders of eBay that they had a company with a huge value depending on one relatively simple software application, and that there was no excuse for this application being other than entirely reliable. I commented that if their software people were telling them that such failures were inevitable, they should all be fired and replaced; I never received a reply.
So just what do we need to teach our students if they are to have the right
viewpoint and skills to construct the complex reliable software systems of tomorrow, and to maintain, extend, and fix the systems in use today? In my experience, undergraduate computer science curricula simply do not regard complex software construction as a central skill to be taught. Introductory courses are dumbed down in an effort to make them fun and attractive, and have sacrificed rigor in designing and testing complex algorithms in favor of fiddling around with fun stuff such as fancy graphics. Most of these courses at this stage are using Java as a first language, and all too often Java is the only language that computer science graduates know well.
The original CrossTalk article was widely regarded as an anti-Java rant (one follow-up article was titled “ Boffins Deride Java”). 9 It is indeed the case that the use of Java complicates basic education of programmers. It’s not impossible to teach the fundamental principles using Java, but it’s a difficult task. The trouble with Java is twofold. First it hides far too much, and there is far too much magic. Students using fancy visual integrated development environments working with Java end up with no idea of the fundamental structures that underlie what they are doing. Second, the gigantic libraries of Java are a seductive distraction at this level. You can indeed put together impressive fun programs just by stringing together library calls, but this is an exercise with dubious educational value. It has even been argued that it is useless to teach algorithms these days. It’s as though we decided that since no one needs to know anything about how cars work, there is no point in teaching anyone the underlying engineering principles. It is vitally important that students end up knowing a variety of programming languages well and knowledge of Java libraries is not in itself sufficient.
Although the article was regarded as being anti-Java that misses the main point, which is that the curriculum lacks fundamental components that are essential in the construction of large systems. The notions of formal specification, requirements engineering, systematic testing, formal proofs of correctness, structural modeling, and so forth are typically barely pres-
ent in most curricula, and indeed most faculty members are not familiar with these topics, which are not seen as mainstream. For an interesting take on the importance of a practical view, see Jeff Atwood’s column discussing the need to teach deployment and related practical subjects. 1
Another area of concern is that the mathematics requirements for many CS degrees have been reduced to a bare minimum. An interesting data point can be found in the construction of the iFacts system, 8 a ground-based air-traffic control system for the U.K. that is being programmed from scratch using SPARK-Ada2 and formal specification and proof of correctness techniques. It has not been easy to find programmers with the kind of mathematical skills needed to deal with formal reasoning. And yet, such formal reasoning will become an increasingly important part of software construction. As an example, consider that of the seven EAL levels of the Common Criteria for security-critical software, the top three require some level of formal reasoning to be employed. 3
It is true that a lot of software development is done under conditions where reliability is not seen as critical, and the software is relatively simple and not considered as safety- or security-critical. However, if this is all we train students for then we won’t have the people we need to build large complex critical systems, and furthermore this kind of simple programming is exactly the kind of job that can be successfully transferred to countries with less expensive labor costs. We are falling into a trap of training our students for outsourceable jobs.
The original article in CrossTalk
References:
Archives