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
undergraduate
computer science
curriculums simply
do not regard
complex software
construction as
a central skill to
be taught.
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-
it’s not impossible
to teach the
fundamental
principles using
Java, but it’s a
difficult task.
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
