Terry, Glenn, et al:
I think I get the automata arguments. But let me try this:
I don't see how, in the general case, one can enumerate the variables
needed to entirely describe a design problem. To design something right
the first time (as opposed to the 'fast failure' approach) would pretty
much require that level of knowledge. At it seems to me that sufficient
information simply isn't available at the outset.
So the 'fast failure' approach is really the only reasonable way to go
about it.
Cheers.
Fil
Terence Love wrote:
> Hi Glenn,
>
>
> The automata problem also fascinated me. The conclusions I came to was that
> it isn't intrinsically a conflict. It doesn't 'automate' design, and, it
> points up a problem in the politics of how design has been defined.
> Radically, the automata problem suggests a need to redefine design activity
> in a way that is independent of the hegemony of traditions of design
> practice and the education of practitioners.
>
> My reasoning on it went something like this (it's in my PhD thesis):
>
> The solution to the problem is pointed to by one theorem of finite automata
> that states (If I remember right it's something like!),
>
> "If a problem can be expressed in variables in the language of finite
> automata then a solution can be found by manipulation of those variables
> using that language"
>
> One way of looking at this, is that the use of automata does not automate
> the activity of designing as a whole and human design activity does not
> disappear. Simply, the location of design activity and the types of design
> skills required to 'do design' change.
>
> The locus of design problems changes to 'designing the original _problem_ as
> a representation in the language of finite automata' (rather than designing
> representations of solutions in the languages of sketching, engineering
> drawing, etc).
>
> The skills required of a design practitioner are then the skills to envisage
> a solution, which is the representation of the original problem in the
> language of finite automata. These design skills are very different skills
> from those currently taught to budding designers or possessed by the current
> generation of 'traditional' design practitioners. The gap is not so great
> when seen from within engineering design fields b3casue there has already
> been an historical shift from craft tools to more abstract representational
> manipulation in for example understanding shape, movement and product
> behaviours, and in optimising solutions.
>
> This idea that the scope if design activity changes is also a useful
> perspective for solving several other problems in the area of defining 'what
> is design'. In particular, it mutually locates the activities of design
> practice and design research. The focus of design research is to improve and
> 'automate' current design practices and skills. This offers the possibility
> and opportunity for designers to drop old design practices and to take up
> new, more effective, more advanced, design practices.
>
> Locating the automata issue in a longer-term picture, design practices have
> changed a lot over time. The changes over single generations, however, have
> been relatively small and accommodated by professional development. This has
> lead in each generation to an illusion and a desire among practitioners and
> educators to define 'design' as whatever design practitioners do at this
> moment. Taking the long view and including the automata issue suggests it is
> better to define 'design' independently of what we as designers think is
> design from looking at our practice.
>
> Thoughts?
>
> Cheers,
> Terry
>
> ===
> (c) Dr. Terence Love
> Dept of Design
> Curtin University
> Tel/Fax: +61 (0)8 9305 7629 (Home office)
> Mobile: 0434975 848
> [log in to unmask]
> ===
--
Filippo A. Salustri, Ph.D., P.Eng.
Department of Mechanical and Industrial Engineering
Ryerson University
350 Victoria St, Toronto, ON, M5B 2K3, Canada
Tel: 416/979-5000 ext 7749
Fax: 416/979-5265
Email: [log in to unmask]
http://deed.ryerson.ca/~fil/
|
