Introduction
It is commonly supposed that software engineering is—and should be—focused on technical and scientific issues, such as correctness, efficiency, reliability, testability, and maintainability. Within this constellation of important technological concerns, it might seem that design aesthetics should hold a secondary, marginal role, and that aesthetic considerations might enter the design process, if at all, only after the bulk of the engineering is done. This article discusses the important role that aesthetics can play in engineering, and in particular in software engineering, and how it can contribute to achieving engineering objectives.
background
Certainly, aesthetic considerations have not been completely absent from software engineering. For example, the development of structured programming ideas was accompanied with conventions for the textual layout of programs, which aimed for conceptual clarity, but also aesthetic appeal. (Even the older programming techniques relied on the aesthetic layout of flowcharts.) Knuth (1992) has advocated a practice of literate programming in which composites of programs and their documentation are treated as “works of literature.” Elegance has been discussed as a criterion of programming-language design since the 1960s (MacLen-nan, 1997, 1999). Furthermore, software engineers have tended to prefer elegant algorithms (Gelernter, 1998) where the criteria of elegance have been inherited primarily from mathematics and theoretical science, in which beauty is a widely acknowledged value (Curtin, 1982; Farmelo, 2002; Fischer, 1999; Heisenberg, 1975; King, 2006; McAllister, 1996; Tauber, 1997; Wechsler, 1988; Wickman, 2005). In these and similar cases, however, there has been little direct work on an aesthetic theory for software.
One exception to the relative lack of explicit work on software aesthetics is the research program in aesthetic computing pursued by, for example, Fishwick (2002) and Fishwick, Diehl, Lowgren, and Prophet (2003). He argues that traditional program representations (such as textual programs and graphs) do not engage our aesthetic senses, and that they are abstract and uninteresting. However, because software concepts are abstract, they do not have a natural sensuous representation, and so Fishwick argues that they should be represented metaphorically (e.g., by visual or sculptural metaphors), and that the “craft-worthy, artistic step” is the choice of metaphor and the expression of the algorithm in terms of it. This metaphorical work (not the textual program, which is secondary) is then the primary medium for the aesthetic expression and appreciation of software (Fishwick, 2002). Recent developments in aesthetic computing are collected in Fishwick (2006).
Software engineering is a new discipline, and so it does not have a long aesthetic tradition as do many of the other arts and engineering disciplines. Therefore, it is helpful to look at well-established disciplines that have significant similarities to software engineering. One of these is mathematics, in which we may include theoretical science, which has in common with software engineering the fact that formal considerations dominate material considerations (explained below). As is well known, aesthetic considerations are important in theoretical science and mathematics (Curtin, 1982; Farmelo, 2002; Fischer, 1999; King, 2006; McAllister, 1996; Tauber, 1997; Wechsler, 1988; Wickman, 2005), and we will find Heisenberg’s (1975) remarks on beauty in the exact sciences to be informative.
Another source of useful analogies comes, perhaps surprisingly, from the structural engineering of towers and bridges, which has in common with software engineering the fact that teams engage in the economical and efficient design and construction of reliable, large, complex systems, the failure of which may be expensive and dangerous. We will appeal especially to Billington’s (1985) insightful investigation of the role of aesthetics in structural engineering. aesthetics, formality, and software
Importance of Aesthetics
Billington (1985) identifies three criteria of good design—the three Es of efficiency, economy, and elegance—which he associates with three dimensions of the design process: the scientific, the social, and the symbolic (the three 5s). All of these also apply to software engineering. Efficiency is primarily a scientific issue since it deals with the physical resources necessary to meet the project’s requirements. In structural engineering, the fundamental requirement is safety, which is also important in software engineering, in which other important issues are real-time response, dynamic stability, robustness, and accuracy, among others.
The second criterion, economy, which treats benefits and costs, is a social issue because it depends on a society’s values, both monetary and other. Certainly, many economical considerations can be reduced to money, which is almost the common denominator of value in the modern world, but it is problematic, at very least, to treat some costs, such as human death and suffering, in financial terms. The economy of a design depends on many social factors, including the costs of materials, equipment, and other resources; the availability and cost of labor; governmental regulations; and so forth. As a consequence, the economic worth of a design is more difficult to evaluate and predict than its efficiency.
This brings us to elegance, the aesthetic criterion, and while it will probably be granted that beautiful designs are preferable for their own sakes (other things being equal), Billington (1985) gives compelling arguments for the engineering worthiness of elegant designs, which also apply to software engineering.
As will be explained, elegance is a means of conquering complexity. In terms of their numbers of components and their interactions, software systems are some of the most complicated systems that we design. Even programs as simple as text editors may have hundreds of thousands of lines of code. Furthermore, these components (the individual programming-language statements) interact with each other in complex ways so that the number of potential interactions to be considered rises to at least the square of the number of lines of code. In addition, software engineers are at a disadvantage compared to other engineers for the components of programs are abstract operations, whereas designers in other engineering disciplines can depend on their physical intuition to aid their understanding (Ferguson, 1992).
Software engineers have designed various analytical tools to help them conquer this complexity, but it is important to understand the inherent limitations of analysis. Analysis makes use of models (especially mathematical models) to understand some system of interest. These models are useful because they make simplifying assumptions that permit the models to be understood more easily than the modeled systems. An effective model simplifies matters that are irrelevant to its purpose so that our limited cognitive resources can be devoted to the relevant matters. Often, the simplifying assumptions are made consciously; for example, we may use a linear model for a nonlinear system if we have reason to believe that the nonlinear effects are irrelevant to our concerns. However, models also typically make tacit simplifications because certain factors are assumed to be irrelevant or, in some cases, because some factors have never been considered at all. For example, Billington (1985) observes that the Tacoma Narrows Bridge collapsed 4 months after it was opened because aerodynamic stability had not been considered a factor in bridge design (see also Fergu son, 1992). The problem is more severe for more complex systems because our cognitive capacities are strictly limited, therefore so is the completeness of the model; hence, the gap between the modeled factors and the system increases with increasing system complexity. The risk of intentionally or inadvertently omitting relevant factors increases with system complexity.
Billington (1985) observes that in structural engineering, elegance compensates for the limitations of analysis. This is because in an elegant design, the disposition and balance of the forces are manifest in the design’s form, and therefore designs that look stable are in fact stable. More generally, designs that look good are good. For example, the Tacoma Narrows Bridge and several other bridges, which were designed on the basis of extensive mathematical analysis and computer models, collapsed because aerodynamic stability was not included in the analysis, whereas earlier bridges, whose designs were guided by aesthetic judgment, were aerodynamically stable. If we generalize from the specifics of structural engineering, we may say that elegant designs are manifestly correct, safe, efficient, and economical. But why should we expect any correlation between aesthetic values and engineering values?
Billington (1985) argues that in structural engineering, Louis Sullivan’s architectural maxim “form follows function” is not as applicable as its converse, “function follows form.” Sullivan’s principle asserts that a building’s function should strongly determine its form. In structural engineering, however, there are typically many ways to fulfill a particular function (such as bridging a river at a particular location) for “engineering design is surprisingly open-ended” (Ferguson, 1992, p. 23). Therefore, since there is wide choice of form, the engineer can choose designs that manifest a stable disposition of forces, that is, elegant designs. More abstractly, engineers who are guided by elegance choose to work in a region of the design space in which aesthetic values correspond to engineering values (that is, function follows form). Therefore they can rely on their aesthetic judgment, which is a highly integrative cognitive faculty, to guide the design process.
The same considerations apply even more so in software engineering, where there are typically very many possible software solutions to an application need. That is, software engineers can compensate for the limitations of analysis by limiting their attention to designs that are elegant, that is, manifestly correct, efficient, maintainable, and so forth. In this region of the design space, where aesthetic values correspond to engineering values—where good designs look good—designers can rely on their aesthetic judgment to guide them to good engineering solutions.
Elegance is associated with the symbolic dimension of a design because, in the appropriate region of the design space, aesthetic values symbolize engineering values. However, design aesthetics can also symbolize less tangible values that are nevertheless important; this may be called the ethical aspect of the design. For example, a design may be straightforward or subtle, or it may be well organized or a rat’s nest; it may be monolithic or modular, and so forth. That is, the design accentuates or suppresses various attitudes, concerns, and other values, which are therefore kept before the designers’ eyes or are allowed to escape their attention. An aesthetically sensitive engineer will tend to conform to the aesthetic values already exemplified by the design, and so they will tend to perpetuate the nonaesthetic values symbolized by its aesthetic qualities. Elegance calls forth more elegance.
As Heisenberg (1975) remarks, the ethical dimension is especially important in long-term group projects. As an aesthetic object, the ongoing project symbolizes the constellation of values around which it is organized. In this way, new project members are encouraged to conform to these values and maintain the integrity ofthe project. Heisenberg compares the generations of scientists who construct a beautiful theory to the medieval cathedral builders, who “were imbued with the idea of beauty posited by the original forms, and were compelled by their task to carry out exact and meticulous work in accordance with these forms” (p. 176).
So far, I have focused on the importance of aesthetics for the designers of software systems, but it is also important for its users. It is perhaps obvious that, other things being equal, users would prefer using aesthetically attractive software to using unattractive alternatives. However, many people’s occupations are dominated by interaction with software systems, and software is coming to occupy many people’s leisure activities as well. Therefore, the aesthetic dimension of software can have a significant effect on users’ quality of life.
Many people’s experience of software is dominated by fear, which results largely from the unpredictability of their interactions with it. People interact with technological devices better to the extent that they can form a cognitive or conceptual model of the workings of the system (Norman, 1988, 1998, 2005). The model does not have to represent the actual internal operation of the system, but it has to be accurate enough to allow users to interact with it reliably. In the same way that people will use an elegantly designed bridge with more confidence—for it looks as stable and strong as it is—they will be able to use elegantly designed software with confidence for its external form will reflect and imply its internal logic.
As users become more educated about the aesthetic qualities of software, they will prefer elegant software and therefore encourage its production with a corresponding improvement in the scientific and economical aspects of software systems. Billington (1985) has pointed out the role of an aesthetically knowledgeable public in European bridge design, where the aesthetics of structural engineering projects are regularly critiqued in public.
Formality and Aesthetics
How can elegant software be achieved? The products of all the arts (technical arts as well as fine arts) can be analyzed in terms of form and matter. In this context, matter refers to the raw material of the art, the relatively neutral stuff on which an art imposes its particular kind of form. The matter of painting includes the canvas, paints, and brushes; the matter of music includes duration, pitches, timbres, and so forth, which are the raw ingredients of a musical composition. The matter of programming is the hardware, which provides relatively neutral ground (comprising memory cells, machine operations, etc.) on which a program imposes a particular form, organizing the computer’s operations in time and memory space.
Any artist (or technologist) must be sensitive to both the formal and material characteristics of the art, but software engineering is unusual in the degree to which formal considerations dominate material considerations. Indeed, the correctness and efficiency of software is usually treated entirely from a formal perspective, and material concerns (e.g., the limitations and capacities of specific hardware) are addressed as second-order effects. In spite of enormous changes in the medium of computation (relays, vacuum tubes, transistors, VLSI), we still use many of the same algorithms that were used in the earliest days of computing (and in some cases even before computers were invented). This highly formal quality of the software art distinguishes it from most other artistic and engineering disciplines.
As a consequence, in establishing aesthetics for software engineering, it is helpful to look to other longer established enterprises where formal issues dominate the material. In particular, we can learn from the elegance and aesthetics in mathematics and the theoretical sciences, which have similar standards of correctness, generality, simplicity, elegance, and beauty (e.g., Curtin, 1982; Farmelo, 2002; Fischer, 1999; King, 2006; McAllister, 1996; Tauber, 1997; Wechsler, 1988; Wickman, 2005), which are also applicable to software.
Of course, the role of aesthetics in mathematics and science is itself a topic of discussion, but the analysis of Heisenberg (1975) provides a good starting point. The formality of these disciplines (and of software) suggests a Platonic approach to aesthetics, which explains beauty in terms of formal structure. Indeed, as Heisenberg remarks, aesthetic concerns were at the root of Western science in Pythagoras’ correlation of musical pitch with numerical ratios: The most beautiful (consonant) intervals were found to correspond to the simplest whole-number ratios (1/2, 2/3, 3/4).
According to classical theories of aesthetics (as represented primarily by Plato and Aristotle), the beauty of a work resides in a symmetric, orderly, and harmonious relation of the parts to each other and to the whole. Our aesthetic response arises from a comprehension of these formal relationships, and thus there is a correspondence between beauty and in telligibility. As we saw for elegance, therefore, engineers’ aesthetic responses can be used to guide software design and to evaluate its result.
These aesthetic principles can be applied both to the static relations within a software system and to the dynamic relations generated by the running system; we begin with the static relations.
As stated by Heisenberg (1975, p. 174), “Beauty is the proper conformity of the parts to one another and to the whole.” Specifically, there should be a harmonia among the parts, which in ancient Greek meant that they fit together well. They should be arranged symmetrically and be meaningfully ordered; finally, they should be of similar size and of a size and number that is easy to comprehend. In short, the conformity of the parts to one another coincides with their intelligibility.
A beautiful design is characterized also by the conformity of the parts to the whole. Classically, this means the whole has an organic unity similar to that of a living organism. Therefore, the parts fulfill complementary functions to constitute the whole, which in turn defines the relationships of the parts to each other; the parts and the whole are mutually determinative. In short, the design has integrity.
The preceding criteria are intrinsic to the work, but classical aesthetics also addresses the extrinsic relation of the work to its perceivers: The parts should be of such number and size that they can be easily discriminated, and the whole should be of a perceptible size and capable of being held in the perceiver’s memory. Obviously, when applied to software, these criteria depend in part on the visual presentation of the program, which may be enhanced by visual programming languages. More generally, an aesthetic design conforms to the perceptual, cognitive, and memory abilities of human beings; in these cases, the perceiver has the satisfaction of comprehending the system’s formal structure.
Of course a program is more than an object of contemplation; it is a static structure that defines an infinite set of possible execution sequences (conditioned by possible environment states). Programming is difficult because an informal idea of these possible execution sequences must be expressed by a static structure (the program) that can control a computer to generate any of the desired sequences. Therefore, software design has similarities to the use of mathematics in the theoretical sciences, which seeks to express observed regularities in mathematical laws. Thus, we can benefit from Heisenberg’s (1975) insights into the role of beauty in science, as well as those of others (Curtin, 1982; Wechsler, 1988).
Embodiment and software Aesthetics
Fishwick (2002) has criticized traditional visual presentations ofprograms forbeing “aesthetically-challenged and Platonic” and ” largely devoid of texture, sound, and aesthetic content,” and he has advocated aesthetic programming with the goal of crafting software with “sensory appeal.” Indeed, even Plato, who argued that beauty is rooted in formal relations among abstract ideas, advocated perceptible beauty (mirroring the formal relations) as a route toward appreciation of abstract beauty (e.g., Symposium, 209e-212a). Therefore the visual form of software is relevant to its aesthetics and affects our intellectual and emotional response to it.
Indeed, in recent decades psychologists have come to recognize the important role that embodiment plays in human cognition (e.g., Gibbs, 2006; Lakoff & Johnson, 1999), and Lakoff and Nunez (2000) have argued that abstract mathematical concepts and our intuitions about them are grounded in our sensorimotor skills and experiences as living beings. For example, our basic intuitions about sets arise from our experience with physical containers.
Humans have a deep, intuitive understanding of the physical world and of our embodied relation to it, which is part of our genetic heritage or is acquired in early childhood. People normally feel pleasure when acting skillfully, and that feeling of satisfied competence is part of the psychological feedback process that improves human skill. Therefore, one way to increase pleasurable interactions with software, for software engineers as well as for users, is to design it so that it conforms to our embodied sensorimotor skills, and therefore engages them pleasurably. For example, this can be accomplished by designing interfaces that use actual or simulated physical interactions as a way of interfacing with abstract structures and systems. Thus, Karlsson and Djabri (2001) suggest that when objects are manipulated on a screen, they should mimic the familiar inertia, elasticity, and so forth of physical objects (see also Norman, 1998). Therefore, an increasing focus on embodiment will bring software aesthetics closer to the less formal (more material) aesthetics of architecture and other artistic, design, and engineering disciplines.
future trends
Along with increasing awareness of the importance of emotional intelligence (e.g., Goleman, 2005) and embodied understanding, there has come an appreciation of the role of aesthetics in mathematics, science, and engineering (e.g., Wickman, 2006). Historically, there has been little explicit work on software aesthetics, but that is beginning to change (Fishwick, 2006; Gelernter, 1998). I propose that we can progress by four simultaneous, interrelated activities, which I will call experiment, criticism, theory, and practice.
By experiment, I mean the conscious application of aesthetic principles in program design and the empirical evaluation of the results, including an aesthetic analysis both by the designers and by other software engineers (since software engineering is, ultimately, a social process). In addition to experiments designed explicitly to test aesthetic hypotheses, every software engineering project should be an implicit or explicit aesthetic experiment.
Criticism is fundamental to all the arts. In addition to informing the public about the aesthetic quality of works, it raises aesthetic issues and makes them salient for consumers and artists. Artists in particular articulate a position relative to criticism, perhaps responding with their own criticism, and may adapt their art either in conformity or reaction to the criticism. Thus, criticism is an important feedback process in the evolution of aesthetics, in the formulation of aesthetic principles, and in the aesthetic education of consumers.
By theory I refer to our knowledge of cognitive and affective neuropsychology, which improves our understanding of human aesthetic response and its relation to cognition; this growing body of theory will help to explain experimental results and will suggest new experiments. Nevertheless, human aesthetic response and cognition are both complex and poorly understood, and thus for some time the application of aesthetic principles in software engineering will remain a practical matter with a weak theoretical basis.
This brings us to the matter of practice. The long history of aesthetic debate in philosophy and the fine arts suggests that beauty is not a simple matter of conformity to a few aesthetic principles. Therefore, in the art of programming, as in the other arts, we expect aesthetic principles to provide general guidelines, within which—and occasionally outside of which—designers exercise their aesthetic judgment. Indeed, all expert behavior is characterized by behavior that is broadly in conformity with normative rules, but ultimately free of them (Dreyfus & Dreyfus, 1986); so also with software design.
For the potential benefits of aesthetically designed software to become reality, we will need aesthetics to be a part of the education of every software engineer (cf. Wickman, 2005). Since the goal is for all software design to be guided by programmers’ well-honed sense of elegance and aesthetic judgment, aesthetic issues should be addressed in all software design courses, not just in one course devoted to software aesthetics. To accomplish this, all computer science educators will need to become more attentive to aesthetics.
conclusion
We have seen that attention to aesthetics in software engineering can have practical benefits and also improve designers’ and users’ emotional response to software. Elegant software results from choosing to work in that region of the design space where good designs also look good, therefore aesthetically sensitive programmers can use this highly integrative cognitive faculty to guide their design decisions. Because of the predominantly formal character of software, Platonic aesthetics is most appropriate as it is in mathematics and theoretical science; according to this aesthetics, beauty resides in the conformity of the parts to one another and to the whole. Nevertheless, the more sensuous aspects of aesthetics are also relevant for they engage our embodied understanding and sensorimotor skills. The full benefits of attention to aesthetics will require ongoing pursuit of the aesthetic principles of software and their integration into computer science education.
key terms
Aesthetics: Aesthetics is a set of principles and practices pointing toward a particular notion of beauty; it is also the discipline that studies such principles and practices.
Elegance: Refers to beauty, grace, harmony, beautiful simplicity, restraint, clarity, and precision.
Embodiment: Refers to the important role played by the human body, including the brain, in cognition, language, imagination, and other mental processes.
Ethical Dimension: The ethical dimension (or aspect) of a software design refers to the influence of the design on the behavior of the engineers working on it.
Execution Sequence: Is the sequence of instructions executed in a particular run of a program (i.e., when provided particular inputs).
Normative: Provides norms or standards of behavior, practice, and so on.
Sensorimotor Skills: Refers to those skills by which we interact fluently and competently with the world, integrating sensory perception and motor action.
Visual Programming Language: Is a programming language in which programs are displayed in some nontextual form, such as a graph, tree, or nested assembly of tiles.
