Randell described software engineering as “multiperson development
of multiversion programs.” Brooks said
that, in addition to writing code, software engineering required both combining separately written programs
and “productizing” them—that is,
making them suitable for use by people
who had not written them. These topics
usually received little or no attention in
traditional programming courses.
We were able to identify a set of capabilities required to do the things that
Randell and Brooks had identified as differentiating software development from
basic programming. The accompanying
table lists those capabilities but readers
really should read the paper to see what
is meant. They will find detailed, concrete
justifications, definitions, and guidelines.
You used “software systems engineering” to denote the class of programmes
you were discussing. That class included both specialized programmes
and general software engineering programmes. You listed 12 capabilities that
should be imparted to software systems
engineers. They are all engineering capabilities. How should this be used?
tional engineering education taught
methods of designing and constructing reliable products, they proposed
that that software development should
be regarded and taught as an engineering discipline rather than as a branch
How did universities respond to the
After the conferences, software engineering was treated as the area within computer science that studied ways
to produce safe and reliable products.
Some included project management
within the field.
The initial response was to add a
On a number of occasions, you wrote
single one-semester course entitled
“Software Engineering” to CS curricu-
lums. It was not clear what should be
taught in such a course. When I was
assigned to teach that course, I asked,
“What should it cover?” The only an-
swer was “Dave, you are an engineer—
you figure it out.”
Later, as software became more im-
portant, CS departments defined soft-
ware engineering “tracks” that included
additional required courses—such as
compilers, database systems, and soft-
ware test methods. Important aspects
of engineering such as interface design
and fault tolerance were rarely included.
sharp critiques of many of these pro-
grammes.a What was the basis of your
criticisms? Did they produce results?
My first critique 6 complained about
many aspects of the “tracks.” I pointed
out they were teaching topics that interested the teachers rather than what
the students would need to know as
professional software developers.
My second major commentary7 was
written after my university (
McMaster) had formed a new department and
was offering a program designed to be
taught in the engineering faculty rather than the science faculty. It had no
courses in common with the previously
existing CS program. Students took the
same first-year courses as all other engineering students; only at the end of that
common first year could they select software engineering as their programme.
a “Programme” is used in the context of this interview to refer to a course of study at a university and
to differentiate from a software program.
The point of both of these papers
was that software engineering education should be considered professional
education (like architecture, medicine,
law or engineering) rather than based
on a “liberal arts” model like physics or
Our programme was designed to be
accredited by the Canadian Engineering Education Board. In the year we
graduated our first students, two other
Canadian Universities were also accredited and graduated students.
Both papers generated a lot of discussion. The programme described in
the 1998 paper7 was well received by
students and employers. Unlike graduates of CS programmes, our SE graduates could be licensed as professional
engineers after passing the usual law
and ethics exams.
In 2017, you chaired a committee that
wrote a report about software devel-
opment programmes. 1 The resulting
paper takes a capabilities-based ap-
proach to specifying the goals of pro-
fessional programs in software devel-
opment. How does this approach differ
from the more common approaches?
Previous efforts to prescribe the con-
tent of CS and SE programs were based
on the concept of a “Body of Knowl-
edge.” They specified what the students
should know when they graduated.
Noting that these were professional
programs, we chose to specify what the
graduates should be able to do upon
graduation. Our goal was to allow individual institutions to choose the
knowledge and methods that would
be taught provided that they gave the
graduates the required capabilities.
Those who read the 2017 paper will
see that the approach is quite different
from earlier approaches to curriculum
specification. It emphasizes software
development capabilities, not the
name and content of the courses.
The 2017 paper stresses the difference between CS programmes and
professional software development
programmes, basing your approach
on very old observations by Brian Randell (an author of the reports on the
1968 and 1969 conferences) and Fred
Brooks, author of the very popular
book The Mythical Man Month. What
did they say that attracted you?
List of capabilities.
Communicate precisely between developers
Communicate precisely among developers
Design human-computer interfaces
Design and maintain multiversion software
˲ Identify and separate
˲ Document to ease revision
˲ Use parameterization
˲ Design software that can be moved
to many platforms
˲ Design software that is easily extended
˲ Design and maintain products that
will be offered in many versions
Ensure software products meet quality
Develop secure software
Create and use models
in system development
Specify, predict, analyze, and
Be disciplined in development and
Use metrics in system development
Manage complex projects