Issue: March/April 2001 | PDF

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  |  More articles