An extended review.
The Nature and Aesthetics of Design is a book by David Pye (ISBN 0-7136-5286-1, publisher: Herbert Press Limited). David Pye was an architect, industrial designer, and wood craftsman. He was also Professor of Furniture Design at the Royal College of Art, London. He also wrote The Nature and Art of Workmanship (ISBN 1-871569-76-1).
In this chapter the author distinguishes between art and science with the observation that designers have limits set upon their freedom whereas artists typically do not. The idea of design limitations and their liberating effect is an important one which you may recall from Safer C . The author then considers "function" and the fuzzy and unhelpful notion of form-follows-function. He asserts that the major factors in designing devices are considerations of economy and style - both matters of choice. Further, when used, every device produces concrete, measurable, objective results and this is the only sure basis for a theory of design. When reading this I was reminded of eXtreme Programming and testing. Later in the chapter the author talks about systems - that things never exist in isolation - that things always act together and need to be in balance . The author also says that design is not just about getting the intended results it is as much about averting possible consequences of unwanted inputs .
In this very short chapter the author states that invention is the process of discovering a principle whereas design is the process of applying that principle. It is interesting that in his other book there is also a very short chapter in which design and workmanship are distinguished: design can be conveyed in words or drawings, workmanship cannot. Based on this distinction one might say that design and workmanship is the process of applying a principle. (In fact later in the book the author asserts that workmanship is design). He also talks about description  - that the description of an invention describes the essential principle of the device, which is purely a matter of its arrangement.
All but one of the six facets presented have clear parallels in software. The one that's not so clear is that appearance must be acceptable. By analogy the simple non-functional appearance of source code must be acceptable. The chapter discusses the six requirements in the context of how far, if at all, each of the requirements limits the designer's freedom of choice (relating back to chapter 1). One requirement concerns the strength of the components; components must be strong enough to transmit or resist forces. The relationship between strength and size is examined. Large bridges need to support not only their traffic but also their own weight. Economy and minimalism are also briefly discussed (he returns to the theme of economy in a later chapter). Another requirement is that of access. A device may be conceptually self-contained but in truth every device is part of a larger system that man is always part of. "The engines must allow access for the engineer's hands when he is maintaining them". The idea of complexity is briefly touched on "the most characteristic quality of modern devices is their complexity.
This is a short chapter and of limited applicability to software. However, the idea of achieving results by way of intermediary results is covered and has clear parallels with refactoring .
This is a fascinating chapter. The author discusses construction as the idea of making a whole by connecting parts together. He talks about the need for techniques enabling us to vary properties independently and locally. The issue of size crops again and the author states that many techniques, when taken together, are so versatile that they impose hardly any limitations on the shape of the design (that form does not follow function) but that they do impose limitations on its size and that "standard pieces tend to be small". Again I am reminded of Richard Gabriel and Christopher Alexander, both of whom emphasize the importance of components right down to 1/8 of an inch. The second part of the chapter is devoted to skill. He defines any system in which constraint is variable at will as a skilled system. He asserts that skilled systems are likely to be discontinuous; that the intended result is arrived by way of a series of intermediate results. Again the parallels with refactoring are strong. Then there is an illuminating section on speed in which the author says a system with skilled constraints usually gets the intended results slowly because it is easier to maintain constraints if energy is put in slowly. This chapter, particularly the part on skill, has a strong connection to chapter 2 of David Pye's other book (The Nature of Art and Workmanship) where the author makes a distinction between manufacturing and craftsmanship by defining manufacturing as the workmanship-of-certainty and craftsmanship as the workmanship-of-risk. In other words, something can be manufactured, even if made by hand (possibly with the aid of jigs, etc) if the risks involved in its creation are minimal. On the other hand, something is "crafted" if there are ever-present risks involved in its creation; if "the quality of the result is not pre-determined, but depends on the judgment, dexterity and care the maker exercises as he works". Which of these two sounds like software? The second book revolves around the idea that workmanship-of-risk has long been widely valued.
In this chapter the author considers the influence and dangers of similarity; of designing something as an adaptation of an existing design. He again urges us to consider first and foremost the intended results. But on the other hand he points out that if the problem is old, the old solution is likely to be the best (the alternatives are that new techniques have been invented or that all the designers in previous generations have all been fools). The final paragraph considers the influence of similarity again - invention and design are in tension. If you improve your powers of design is it necessarily at the expense of your powers of invention?
This is a somewhat philosophical chapter. The section on improvement in particular talks about the secret of happiness and notes that there is no secret of unhappiness, that avoiding unhappiness does not imply happiness. The section on impossibilities is surprisingly relevant to software. The author mentions abstraction when he writes "We get experience by attending and we do that by abstracting one thing or event from all those in reach of our perception and then ignoring the rest". Or, to use Andrew Koenig's sound-byte, selective ignorance. What has this to do with impossibilities? The author asserts that we can never wish for impossibilities; we can only frame our wishes in terms of past experience, experiences of the possible.
This is a chapter resonating with parallels in software. The author's basic premise is that design requirements are always in conflict and so it follows that all designs are arbitrary. Where and how limitations apply is, ultimately, a matter of choice. However, some of the major limitations of physical design are simply not present in software. For example, a physical design often requires several parts which need to be in the same place at the same time and compromises must be made. This does not apply (or applies much less) to software. Given that all design is arbitrary, it follows that there are no ideal, perfect designs. That is not what design is about. Design is about creating a practical balance between competing and conflicting requirements. And no matter how you strike the balance your boss always wants it sooner and cheaper.
This too is a fascinating chapter. In it the author contends that man performs an immense number of every-day actions which are not necessary. For example, many Paleolithic tools are made with better-than-needed workmanship. There is something very deep about workmanship. Workmanship is design. The author states that "the most noticeable mark of good workmanship is a good surface". What is the surface of software? Isn't it simply the physical appearance of the source code again?
This is an interesting chapter, a flavour of which is best summed up by quoting the opening paragraph. "Architecture is differentiated from engineering and from nearly all other branches of design by the fact that the architect has to act as is no object in the result, except the earth itself, is given. His first preoccupation is neither with how to get the intended result, nor with what kind of result to aim at, but with deciding what the principal objects are."
In this chapter the author again urges the reader to abandon the idea of form and to concentrate instead on results. In the last paragraph of this short chapter he asserts that "economy, not physics, is always the predominant influence because it directly and indirectly sets the most limits." Perhaps the non-physical nature of software is not so relevant after all.
This chapter is also somewhat philosophical in nature. The author argues that since a designer always has some freedom of choice, they have a duty to exercise that freedom with care. The design of physical things in the environment, no matter how small, really matters; designing one motor car for one person to drive means designing millions of cars for thousands of people as scenery. In design, as in art, small things matter. Indeed the author goes further saying "art is not a matter of giving people a little pleasure in their time off. It is in the long run a matter of holding together a civilization." He invites you to consider what would happen if each new generation rebuilt its entire environment so that everything was always new.
This is another thought provoking chapter, this time on aesthetics, beauty, and value. He argues that design appreciation is beauty appreciation. He also questions whether aesthetics matter and touches again on happiness and unhappiness. He argues persuasively that while beds reduce cold, ploughs reduce hunger, and toothbrushes reduce toothache, such devices do not, of themselves, endow happiness. Being cold, hungry and in pain can certainly make you miserable, but for many people being warm, fed and pain-free is not enough to live for. Or, as he puts its, "not having toothache is no goal for a lifetime".
In this chapter the author considers how we look at things and how we see things. These clearly relate to the aesthetics of design (the title of this book) and to taste in design (a topic covered in the next chapter). After a section on the biological process of seeing he draws the distinction between sight and perception; we are born able to see but we have to learn to perceive, that we learn slowly, but then become largely unaware of the skills involved. He again returns to the idea of abstraction, "if we could not ignore we should die" and how perception requires abstraction.
This chapter continues the theme of perception and notes that recognition occurs by means of a few characteristics rather than many. In contrast, he asserts that to experience the beauty of something arises from the totality of its characteristics and their relationships. That "to recognize the style of a design and to appreciate the beauty of it are two quite different things". He argues that design without style is an impossibility and that "any style has positive value for it puts limits on designers' freedom of choice". He also discusses change noting how civilization seems to be losing the concept of continuous change by small variations (that is, civilization seems to be losing tradition).
This chapter starts by considering the role and nature of artists and quickly comes to the conclusion that originality is largely irrelevant to art. The last paragraph ends with a sentence that could have come straight out of  or  "The best designs have always resulted from an evolutionary process, by making successive slight modifications over a long period of time". Originality and innovation often hinder improvement.
The final chapter has few parallels with software that I can perceive. However it does mention the importance of context and it also touches on size again. Many painters maintain that a picture has a "right-size" and that making it smaller or larger will be to its detriment. The theme of size recurs. I'm increasingly sure that making software elements the "right-size" is important in a deep way. I'll leave you with some quotes from Richard Gabriel "build small abstractions only", "buildings with the quality are not made of large modular units", "its modules and abstractions are not too big", "every module, function, class, and abstraction is small".
 Safer C, by Les Hatton. See section 3.1 (p87) on Discipline.
 Patterns of Software, by Richard Gabriel. Part I in particular.
 The Timeless Way of Building, by Christopher Alexander.
 To Engineer is Human (subtitled The Role of Failure in Successful Design), by Henri Petroski.
 Software Requirements and Specifications, by Michael Jackson. See p58 - Descriptions.
 Refactoring, by Martin Fowler.
|Jagger Software Ltd|
|Company # 4070126|
|VAT # 762 5213 42|