Article development led by
What happened to the promise of
rigorous, disciplined, professional
practices for software development?
BY IVAR JACOBSON AND ED SEIDEWITZ
WHAT HAPPENED TO software engineering? What
happened to the promise of rigorous, disciplined,
professional practices for software development, like
those observed in other engineering disciplines?
What has been adopted under the rubric of
“software engineering” is a set of practices largely
adapted from other engineering disciplines: project management, design
and blueprinting, process control,
and so forth. The basic analogy was
to treat software as a manufactured
product, with all the real “
engineering” going on upstream of that—in requirements analysis, design and modeling, among others.
Doing the job this way in other en-
gineering disciplines makes sense be-
cause the up-front work is based on a
strong foundational understanding,
so the results can be trusted. Software
engineering has had no such basis,
so “big up-front design” often just
has not paid off. Indeed, the ethos of
software engineering has tended to
devalue coders (if not explicitly, then
implicitly through controlling prac-
tices). Coders, though, are the ones
who actually have to make the soft-
ware work—which they do, regardless
of what the design “blueprints” say
should be done.
Not surprisingly, this has led to a
lot of dissatisfaction.
Today’s software craftsmanship
movement is a direct reaction to the
engineering approach. Focusing on
the craft of software development, this
movement questions whether it even
makes sense to engineer software. Is
this the more sensible view?
Since it is the code that has to be
made to work in the end anyway, it
does seem sensible to focus on crafting quality code from the beginning.
Coding, as a craft discipline, can then
build on the experience of software
“masters,” leading the community to
build better and better code. In addi-