Re: Human design and natural "design"


"dkomo" <dkomo871@xxxxxxxxxxx> wrote in message news:ddmh0v$1blk$1@xxxxxxxxxxxxxxxxxxxxxx
> Perplexed in Peoria wrote:
> > "dkomo" <dkomo871@xxxxxxxxxxx> wrote in message news:ddiijq$2ok$1@xxxxxxxxxxxxxxxxxxxxxx
> >
> >>Evolution produces organisms which show the appearance of design, but
> >>are not actually designed. Evolution uses random variation and
> >>selection to do this.
> >>[snip]
> >>In the general world of human design, is there anything more than random
> >>variation and selection? Yes, an evaluative memory. As a design
> >>proceeds, it is *guided* using a combination of what has worked in the
> >>past with foresight into what may work in the future.
> >
> > I'm not happy with that word "foresight" since it is evocative of
> > fortune-telling or perhaps of "inspiration".
>
> Part of foresight is ordinary prediction. Part of it is specifying what
> the design is to be in advance. The spec then serves as a target for
> the design process.

Ah! This evokes some thoughts. One area of human designing that I
have some familiarity with is computer software and hardware design.
Such designs are typically very complex and heirarchical. IMO, they
are the only examples of human designs that even approach the complexity
of the designs produced by NS.

There are currently three competing models for the best design practice
to be used in computer software system design. These are "top-down
design", "bottom-up design", and "incremental design".

In "top-down design", you proceed somewhat as you have suggested.
You start with a specification of what the system is supposed to
accomplish. You then break the task down into subsystems, carefully
specify what each of those subsystems is supposed to accomplish, and
carefully specify the interfaces between the subsystems. This completes
design at that level, but the task of designing each subsystem remains.
You keep designing lower and lower level subsystems until you reach
"bedrock". Then you are done. Clearly NS does not use a process remotely
similar to "top down design". Top down design has the property that
you cannot even begin testing your design until the whole thing is
complete.

In "bottom-up design", you start with a much vaguer specification of
what the overall system is supposed to accomplish. You proceed to do
a rough division into subsystems, but you only vaguely specify what
each of these subsystems is supposed to do. You barely specify the
interfaces between subsystems at all.

Next, you choose the most challenging or interesting of those subsystems,
and design that. Continuing in this way, you eventually reach "bedrock"
on one tiny sub-sub-system. You have implicitly specified the behavior
of that subsystem and the interfaces of that subsystem with the rest of
the system. Stepping back up a level, you revisit the design at that
next higher level. The completed specification of one subsystem and its
interfaces now acts as a constrait allowing you to revise the division
into subsystems. Now choose the most interesting of the remaining
undesigned subsystems, and iterate on it.

Moving up and down the tree in this way, you eventually complete the
design. As compared to the top-down approach, this bottom-up approach
does result in the early completion of some subsystems, and it does
permit empirical testing of those subsystems before the entire design
is complete. The downside is that it doesn't allow much design
parallelism. Furthermore, you frequently get some unpleasant surprises
when you get around to designing the "uninteresting" subsystems which
had been put off until last. You discover that what should have been
a simple piece of the system has become an impossible piece, since the
frozen interfaces of the already designed subsystems with which it
interacts just don't provide what the final "easy" subsystem needs.

I might note that the problem-solving algorithm of the General Problem
Solver (Newell, Shaw, and Simon) is a tree-walking process similar to
the "bottom-up" design process that I have described. I will also
note that "bottom-up" design doesn't match very well with what Nature
does either. But one frequently sees objections to NS in which the
objector seems to assume that Nature's design process must be
"bottom-up". These people seem to assume that subsystem designs must
be complete before the overall system can work. How, they ask, could
nature have produced feathers before there were wings to use them, and
how could wings have arisen before there were feathers to make them
useful?

As compared to "top down design", "bottom up design" permits less
design parallelism. If the interfaces and specs of each subsystem
are specified before design of the subsystem starts, then there
is no reason why multiple subsystems cannot be designed in parallel.
But you get into trouble if you attempt bottom up design in parallel.
The interface specifications flowing from below will not match each
other.

Finally, we have the new ideology of "iterative design". This is a
fairly new idea arising in association with something called "Extreme
Programming". The idea here is that you get something up and running
as quickly as possible. It doesn't necessarily do everything that
the ultimate system will do, but at least it does SOMETHING. Then
proceed to make improvements to this design. Each stage of the process
produces a system that does a little more, or does it more efficiently,
or is restructured so as to make further progress possible. At each
stage, we are designing some new subsystems, redesigning existing ones,
and occasionally completely revising the interfaces between subsystems.
Subsystems may even become obsolete.

It is interesting that in this ideology, it is not only the design and
the system that evolves. The target specification evolves as well.
Continual interaction with the "customer" or marketing (a customer
surrogate) is considered essential to the success of this approach.

Of the three approaches, this one permits testing earliest, and it
permits a greater amount of design parallelism than does the
"bottom-up" approach. It does involve a lot of building of components
that you are later going to revise and discard - for this reason it
is probably better suited to software designs than to the design
of space probes.

It can be seen that this "iterative design" approach has a lot in common
with the way that Nature does Her designs. About the only thing that
I can see that is different is in the mutability of interfaces between
subsystems. "Iterative design" requires that interfaces are occasionally
completely revised - sometimes without much change to the resulting
functionality. But Nature seems to find it much more difficult to
revise her interfaces. In this regard, Nature's approach seems to have
more in common with "bottom-up design".


.

Relevant Pages

  • Re: new here, my lang project...
    ... >> actually, this is fairly common, eg, in quake. ... I was not arguing it as good design however, eg, I tend to pass 'other' as ... >> is shared between many subsystems. ... longer have to worry about or manage the actual animations... ...
    (comp.object)
  • Re: How Our Brains Ignore Unpleasant Facts was: Re: The Reasonable
    ... noise resistant, they just won't work as well. ... subsystems that don't have any idea about the other components status, ... It met all design expectations ... above the minimal functional level. ...
    (talk.origins)
  • Re: Microsoft finally acknowledges the security drumbeats
    ... >was formerly in charge of design for VMS (a quite securely designed OS, ... The core architecture design is likely to be the same between the ... it had no security model on ... APIs implemented by plugin subsystems (initially including Posix, OS/2, ...
    (comp.security.unix)
  • Re: Microsoft finally acknowledges the security drumbeats
    ... >was formerly in charge of design for VMS (a quite securely designed OS, ... The core architecture design is likely to be the same between the ... it had no security model on ... APIs implemented by plugin subsystems (initially including Posix, OS/2, ...
    (comp.security.misc)
  • Re: OT: Binary Search - Should They Know It?
    ... Considering you are having problems it would be advisable to design the app ... that the classes inside the DLL are unlikely to change but are reused ... Interfaces - This holds the interfaces for the data objects in the ... Our calculation engine is a monster. ...
    (microsoft.public.dotnet.languages.csharp)