From the Editor
IEEE Software, March/April 2001
Art, Science, and Engineering
Engineering's use of mathematics and science exposes it to the criticism
that it is dry--that it saps the artistic elements out of structures that
are engineered. The same criticism has been applied to software engineering.
How true is this criticism? Does software engineering exclude aesthetics? Or
are programmers' debates about the most beautiful way to format source code
really just the tip of a deep software-aesthetics iceberg?
Far from being antithetical to aesthetics, traditional engineering is largely
concerned with all aspects of design, including aesthetic aspects. Its
designs aren't just limited to shapes and colors. Engineers design
everything from electronic circuits to load-bearing beams to vehicles that
land on the moon. As Samuel C. Florman says in the Existential Pleasures
of Engineering
(St. Martin's Griffin, 1994), "Creative design is the central mission of the
professional engineer."
Consider a comparison of two well-known buildings, the Reims Cathedral in
France and the Sydney Opera House in Australia. The Reims Cathedral, shown
in Figure 1, was completed about 1290; the Sydney Opera House in 1973. The
Reims Cathedral was designed to use materials whose properties were
understood (more or less) at the time.
Figure 1. The Reims Cathedral.
The Sydney Opera House was constructed 700 years after the Reims Cathedral. As
you can see in Figure 2, it's stylistically quite different from the Reims
Cathedral. Its architects used modern materials such as steel and reinforced
concrete, and they employed engineering techniques including computer
modeling to determine how little material could safely be used.
Figure 2. The Sydney Opera House.
Which building you prefer is a matter of taste, but which building can
actually be built is a matter of engineering. It would be possible for
modern builders to construct another Reims cathedral, but it would not have
been possible for 13th-century builders to construct a Sydney Opera House.
The reason is not the 13th century's lack of art but of engineering.
Engineering without art can be ugly, but art without engineering can be
impossible. Engineering does not constrain artistic possibilities. The lack
of engineering constrains artistic possibilities.
So it is with modern software systems. The level of engineering prowess
determines how large a system can be built successfully, how easy it will be
to use, how fast it will operate, how many errors it will contain, and how
well it will cooperate with other systems. Software includes many aesthetic
elements, and software developers have no lack of artistic ambition. What we
in the software industry sometimes lack is the engineering technique that
enables us to realize some of our grandest aesthetic aspirations.
Maturation of Engineering Disciplines
Mary Shaw at Carnegie Mellon University has identified a progression that
fields travel through on their way to professional engineering ("Prospects
for an Engineering Discipline of Software," IEEE Software, Nov.
1990).
The Reims Cathedral was built when civil engineering was in its "commercial"
stage. In software, many commercial-stage organizations achieve respectable
levels of quality and productivity by using carefully selected, well-trained
personnel. They rely on familiar practices and change them incrementally in
pursuit of better products and better project performance.
Some of the problems that commercial production encounters can't be solved by
trial and error, and, if the economic stakes are high enough, a
corresponding science will develop. As the science matures, it develops
theories that contribute to commercial practice, and this is the point at
which true professional engineering practice emerges. At that point,
progress arises from application of scientific principles as well as from
practical experimentation. The practitioners working in the field at that
point must be well educated in both the theory and practice of their
profession.
A Science for Software Development
Software science has been lagging behind commercial software development for
years. Extremely large software systems were developed in the 1950s and
1960s, including the Sage missile defense system, the Sabre airline
reservation system, and IBM's OS/360 operating system. Commercial
development of these large systems proceeded much faster than supporting
research did.
But are we really asking software science to provide the right things? For
many classes of applications, including inventory management systems,
payroll programs, general-ledger software, operating system design, database
management software, language compilers--the list is nearly endless--the
same basic applications have been written so many times that these systems
shouldn't require as much unique design effort as they usually get. Shaw
points out that in mature engineering fields routine design involves solving
familiar problems and reusing large portions of prior solutions. Often these
"solutions" are codified in the form of equations, analytical models, or
prebuilt components.
Science has yet to provide software development with a set of equations that
describe how to run a project successfully. Perhaps it never will. But
science doesn't necessarily have to consist of formulas and mathematics. In
The Structure of Scientific Revolutions (University of Chicago Press,
1970), Thomas Kuhn points out that a scientific paradigm can consist of a
set of solved problems. Reusable software project artifacts are a set of
solved problems--solved requirements problems, estimation problems, planning
problems, design problems, and so on.
We know that software engineering is different from other engineering
disciplines in some respects; perhaps the kind of science that underpins it
is different as well. The one thing we know that is not different is that
software engineers care about the aesthetics of their work. Historically,
perhaps that has focused on source code, and perhaps in the future software
engineers will care just as much about the aesthetics of their reusable
estimates, plans, requirements, designs, and other "solved problems."
Editor: Steve McConnell, Construx Software, 11820 Northup
Way, Suite E200, Bellevue, WA 98008.
E-mail: steve.mcconnell@construx.com
- WWW:
http://www.construx.com/stevemcc/
