    <rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/">
     <channel>
        <title>ACCU  :: The Nature and Aesthetics of Design</title>
        <link>https://members.accu.org/index.php/journals/366</link>
        <description>Professionalism in Programming</description>
        <dc:language>en-us</dc:language> 
        <dc:creator>Administrator</dc:creator> 
        <admin:generatorAgent rdf:resource="http://www.xaraya.org" /> 
        <admin:errorReportsTo rdf:resource="mailto:webeditor@accu.org" />
       <sy:updatePeriod>hourly</sy:updatePeriod>
       <sy:updateFrequency>1</sy:updateFrequency>
       <docs>http://backend.userland.com/rss</docs>


        <h2>Journal Articles</h2>


<div class="xar-mod-head"><span class="xar-mod-title">Overload Journal #54 - Apr 2003 + Design of applications and programs</span></div>

<table border="0" cellpadding="1" cellspacing="0">
    <tbody>
    <tr>
        <td valign="top">
            Browse in :
       </td>
       <td valign="top">

                                            <a href="https://members.accu.org/index.php/journals/">All</a>

                     &gt;                         <a href="https://members.accu.org/index.php/journals/c76/">Journals</a>

                     &gt;                         <a href="https://members.accu.org/index.php/journals/c78/">Overload</a>

                     &gt;                         <a href="https://members.accu.org/index.php/journals/c157/">54</a>
                    (10)
<br />

                                            <a href="https://members.accu.org/index.php/journals/">All</a>

                     &gt;                         <a href="https://members.accu.org/index.php/journals/c13/">Topics</a>

                     &gt;                         <a href="https://members.accu.org/index.php/journals/c67/">Design</a>
                    (236)
<br />

                                            <a href="https://members.accu.org/index.php/journals/c157-67/">Any of these categories</a>

                    -                        <a href="https://members.accu.org/index.php/journals/c157+67/">All of these categories</a>
<br />
</td>
   </tr>
   </tbody>
</table>




<div class="xar-error">
   <p>
 <strong>Note:</strong> when you create a new publication type,
the articles module will automatically use the templates
<em>user-display-[publicationtype].xt</em>
and <em>user-summary-[publicationtype].xt</em>.
If those templates do not exist when you try to preview or display a new article,
you'll get this warning :-)  Please place your own templates in themes/<em>yourtheme</em>/modules/articles . The templates will get the extension .xt there. </p>
</div>
<div class="xar-norm xar-standard-box-padding">
   <h1><strong>Title:</strong>&nbsp;The Nature and Aesthetics of Design</h1>
<p><strong>Author:</strong>&nbsp;</p>
<p>
<strong>Date:</strong> 02 April 2003 22:57:19 +01:00 or Wed, 02 April 2003 22:57:19 +01:00</p>
<p><strong>Summary:</strong>&nbsp;</p>
<p><strong>Body:</strong>&nbsp;<div class="sect1" lang="en">
<div class="titlepage">
<h2><a name="d0e18" id="d0e18"></a></h2>
</div>
<p><span class="bold"><b>Author: David Pye</b></span></p>
<p><span class="bold"><b>Publisher: Herbert Press
Limited</b></span></p>
<p><span class="bold"><b>ISBN: 0-7136-5286-1</b></span></p>
<p>David Pye was an architect, industrial designer, and wood
craftsman. He was also the Professor of Furniture Design at the
Royal College of Art, London. He wrote two books that I know of
(the other one is called The Nature and Art of Workmanship).</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<h2><a name="d0e31" id="d0e31"></a>Chapter 1: Art
and Science. Energy. Results.</h2>
</div>
<p>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 [<a href="#Hatton">Hatton</a>]. The
author then considers &quot;function&quot; 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 purely of choice. Further, that every device when used
produces a concrete, measurable, objective result 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 [<a href="#Gabriel">Gabriel</a>][<a href=
"#Alexander">Alexander</a>]. 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 [<a href=
"#Petroski">Petroski</a>].</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<h2><a name="d0e48" id="d0e48"></a>Chapter 2:
Invention and design distinguished</h2>
</div>
<p>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 [<a href=
"#Jackson">Jackson</a>] - that the description of an invention
describes the essential principle of the device, which is purely a
matter of its arrangement.</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<h2><a name="d0e56" id="d0e56"></a>Chapter 3: The
six requirements for design</h2>
</div>
<p>All but one of the six facets presented have clear parallels in
software. The only one that doesn't is that the appearance must be
acceptable. Since software does not have a physical manifestation
the closest parallel to appearance must be just the names embodied
in a software design. Names matter. 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). The third requirement concerns the strength of the
components; components must be strong enough to transmit (delegate)
or resist forces. The relationship between strength and size is
examined. For example, 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). The fourth requirement of use 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. &quot;The
engines...must allow access for the engineer's hands when he is
maintaining them&quot;. The idea of complexity is briefly touched on:
&quot;the most characteristic quality of modern devices is their
complexity&quot;.</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<h2><a name="d0e61" id="d0e61"></a>Chapter 4: The
geometry of a device</h2>
</div>
<p>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
software refactoring [<a href="#Fowler">Fowler</a>].</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<h2><a name="d0e69" id="d0e69"></a>Chapter 5:
Techniques. Skill.</h2>
</div>
<p>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 <span class=
"emphasis"><em>not</em></span> follow function) but that they do
impose limitations on its size and that &quot;standard pieces tend to be
small&quot;. 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 that a
system with skilled constraints usually gets the intended results
slowly. He gives two reasons for this: because the change is likely
to be discontinuous, and 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). In that
chapter 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 &quot;crafted&quot; if there are ever-present risks involved in
its creation; if &quot;the quality of the result is not pre-determined,
but depends on the judgment, dexterity and care the maker exercises
as he works&quot;. Which of these two sounds like software? The second
book revolves around workmanship-of-risk and the idea that it has
long been widely valued.</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<h2><a name="d0e77" id="d0e77"></a>Chapter 6:
Invention: analogous results</h2>
</div>
<p>In this chapter the author considers the influence and dangers
of similarity (designing something as an adaptation of an existing
design). He 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?</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<h2><a name="d0e82" id="d0e82"></a>Chapter 7: We
can wish for impossibilities. Utility, Improvement, Economy</h2>
</div>
<p>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 &quot;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&quot;. 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.</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<h2><a name="d0e87" id="d0e87"></a>Chapter 8: The
requirements conflict. Compromise.</h2>
</div>
<p>This is a chapter resonating with parallels in software. The
author's basic premise is that design requirements are <span class=
"emphasis"><em>always</em></span> in conflict and so it follows
that <span class="emphasis"><em>all</em></span> 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.</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<h2><a name="d0e98" id="d0e98"></a>Chapter 9:
Useless work. Workmanship</h2>
</div>
<p>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 &quot;the
most noticeable mark of good workmanship is a good surface&quot;. What
is the surface of software? Isn't it simply its physical
appearance? Layout matters.</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<h2><a name="d0e103" id="d0e103"></a>Chapter 10:
Architecture. Inventing the objects</h2>
</div>
<p>This is an interesting chapter, a flavour of which is best
summed up by quoting the opening paragraph. &quot;Architecture is
differentiated from engineering and from nearly all other branches
of design by the fact that the architect has to act as if 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.&quot;</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<h2><a name="d0e108" id="d0e108"></a>Chapter 11:
'Function' and fiction</h2>
</div>
<p>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 &quot;economy, not
physics, is always the predominant influence because it directly
and indirectly sets the most limits.&quot; Perhaps the non-physical
nature of software is not so relevant after all.</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<h2><a name="d0e113" id="d0e113"></a>Chapter 12:
The designer's responsibility</h2>
</div>
<p>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 &quot;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.&quot; He invites you to consider
what would happen if each new generation rebuilt its entire
environment so that everything was always new.</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<h2><a name="d0e118" id="d0e118"></a>Chapter 13:
The aesthetics of design</h2>
</div>
<p>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, &quot;not
having toothache is no goal for a lifetime&quot;.</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<h2><a name="d0e123" id="d0e123"></a>Chapter 14:
Perception and looking</h2>
</div>
<p>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, &quot;if we could
not ignore we should die&quot; and how perception requires
abstraction.</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<h2><a name="d0e128" id="d0e128"></a>Chapter 15:
Taste and style</h2>
</div>
<p>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 &quot;to recognize the style of a design and to
appreciate the beauty of it are two quite different things&quot;. He
argues that design without style is an impossibility and that &quot;any
style ... has positive value ... for it puts limits on designers'
freedom of choice&quot;. He also discusses change noting how
civilization seems to be losing the concept of continuous change by
small variations (ie seems to be losing tradition).</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<h2><a name="d0e133" id="d0e133"></a>Chapter 16:
Originality</h2>
</div>
<p>This chapter starts by considering the role and nature of
artists but 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 [<a href=
"#Gabriel">Gabriel</a>] or [<a href="#Alexander">Alexander</a>]
&quot;The best designs have always resulted from an evolutionary
process, by making successive slight modifications over a long
period of time&quot;. Originality and innovation often hinder
improvement.</p>
</div>
<div class="sect1" lang="en">
<div class="titlepage">
<h2><a name="d0e144" id="d0e144"></a>Chapter 17:
The common ground between visual art and music. What we really
see</h2>
</div>
<p>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 &quot;right-size&quot; 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 &quot;right-size&quot; is important in a deep
way. I'll leave you with some quotes from Richard Gabriel &quot;build
small abstractions only&quot;, &quot;buildings with the quality are not made
of large modular units&quot;, &quot;its modules and abstractions are not too
big&quot;, &quot;every module, function, class, and abstraction is
small&quot;.</p>
</div>
<div class="bibliography">
<div class="titlepage">
<h2><a name="d0e149" id="d0e149"></a>References</h2>
</div>
<div class="bibliomixed"><a name="Hatton" id="Hatton"></a>
<p class="bibliomixed">[Hatton] Les Hatton, Safer C. See section
3.1 (p87) on Discipline.</p>
</div>
<div class="bibliomixed"><a name="Gabriel" id="Gabriel"></a>
<p class="bibliomixed">[Gabriel] Richard Gabriel, Patterns of
Software. Part I in particular.</p>
</div>
<div class="bibliomixed"><a name="Alexander" id="Alexander"></a>
<p class="bibliomixed">[Alexander] Christopher Alexander, The
Timeless Way of Building.</p>
</div>
<div class="bibliomixed"><a name="Petroski" id="Petroski"></a>
<p class="bibliomixed">[Petroski] Henri Petroski, To Engineer is
Human (subtitled The Role of Failure in Successful Design).</p>
</div>
<div class="bibliomixed"><a name="Jackson" id="Jackson"></a>
<p class="bibliomixed">[Jackson] Michael Jackson, Software
Requirements and Specifications. See p58 - Descriptions.</p>
</div>
<div class="bibliomixed"><a name="Fowler" id="Fowler"></a>
<p class="bibliomixed">[Fowler] Martin Fowler, Refactoring.</p>
</div>
</div>
</p>
<p><strong>Notes:</strong>&nbsp;</p>
<p><em>More fields may be available via dynamicdata ..</em></p>
</div>
</channel>
</rss>
