Jim writes (in a bit of text that should be read again in whole, if you
haven't already done that):

> In my opinion OO Design is in the same boat as OO
>  Programming; old wine, new bottle.  I have in my possession
>  a 1980-something reprint of the proceedings of the Seldom
>  Met Users Group (SMUG) dating from ~1979. One of the
>  articles therein is titled; "Design To Throw Away", or
>  something very similar.  In that article the author, (David
>  Greer?, somebody from Robelle anyway) writes of the
>  necessity to keep programs and procedures small and
>  disposable. By doing so the design/programming team never
>  has such an investment in a piece of work that they would
>  rather salvage what they have than scrap it all and start anew.
>
>  Is this not in essence OO design, put much more simply and
>  in a form that nearly anyone can understand?  Here we have in
>  concrete terms the exact purpose of OO design.  To break
>  things down into the bits that do one thing well, and that can
>  be freely discarded, replaced, and reworked; without impacting
>  any other portion of a system.

When I used to teach, I used to say the OO programming is nothing much more
than the rediscovery of the subroutine. Perhaps surprisingly, I used to give
virtually identically the same lectures in both evolutionary biology and
computer engineering classes

The inevitable necessities of designing modular systems, with high levels of
cohesiveness but very low couplings, is critically necessary to minimize the
costs of pleiotropy. While very few engineers or programmers know the word
"pleiotropy", everyone knows its effects.

I posted the following post to sci.bio.evolution four years ago, in July,
1997. If you read it carefully, you'll see that it is virtually identical to
Jim's posting. OO programming and design wasn't discovered just a few years
ago; it's been part of life on this planet for 3.8 billion years.

There are perhaps only a couple of words that may need to be defined first in
order for it to make sense: simply equate "genome" with "code" and
"phenotype" with "behavior".

Perhaps the moral of greatest interest occurs towards the end of the material
below. That is that the nature of evolution for systems designed future
high-speed evolvability under as-yet unknown environments demand
modularization and the minimization of pleiotropic effects, to the greatest
possible degree attainable.

Wirt Atmar

=======================================

Zia Khan writes:

>might someone define the term "pleiotropy"?

Literally, pleiotropy means "at more than one turn." In that, every engineer
deeply knows the meaning of pleiotropy (although very few actually know it by
that name).

What the word means in common terms (to both biologists and engineers) is:
"Change one a single item (a gene, a bit of code in a software program, the
placement of a mechanical strut) and other subsystems may be affected in
wholly unexpected manners."

In politics, the effect is known as "the law of unintended consequences," and
that too is the same thing. Pleiotropy is an inevitable consequence of all
complex systems, whether the system be ecological, social, mechanical, or
genetic.

The twin effects of pleiotropy (where one gene affects many "traits") and
polygeny (where one "trait" is the product of many genes) work to create a
complex web of genotype-phenotype interactions that renders any simple
causative analysis fruitless. But that fruitlessness is equally part and
parcel of all complex systems.

The thread that has been proceeding in this newsgroup for some time now
concerning the nature of complexity has always been of great interest to
engineers, especially those engineers that design very complex systems. The
notions of complexity and pleiotropy are intimately intertwined. In order to
bring some sense of analytical order to the subject within engineering, the
definitions of complexity are generally broken into two parts: explicit and
implicit complexities.


EXPLICIT OR APPARENT COMPLEXITY

Integrated circuits are now approaching ten million transistors on a single
chip (Pentium Pro processors already have 2 million transistors). Although
such a parts count begins to approach a human incomprehensibility, a simple
parts count cannot be used as a reliable measure of complexity.

The notion of apparent or explicit complexity depends strongly on the
language (or notation) that is used to describe a complex system.
Repetitions, symmetries, and other similar regularities quite obviously tend
to work to minimize the apparent complexity of a structure. A memory chip
with several million transistors is intuitively not as "complex" as a
microprocessor with only a few thousand transistors, thus engineers and
mathematicians have a tendency to speak of minimum description length (MDL)
notations. An MDL captures, generally without loss of information, the
"essence" of a complex structure -- and thus by itself becomes a metric of
the explicit complexity of the structure.


IMPLICIT COMPLEXITY

D.V. Steward wrote in 1981 in an engineering text that "[Implicit] complexity
is how much more the whole is than just the sum of its parts." While that
definition may seem unusually vague for engineering, and without calculable
value, Steward's definition is nonetheless commonly used and often quoted.

Engineers who work on very complex systems tend to define two additional
qualities as attributes of complexity: "coupling" and "cohesion." Cohesion is
a measure (somehow calculated) of how closely the internal parts that make up
a module belong together when seen from different perspectives.

Coupling, in contrast, measures how much the submodules interact. Good
structuring and clever systems design works to  partition complex systems
into minimally interacting modules by reducing the implicit complexity (that
complexity over and above the MDL) by minimizing pleiotropic interactions
between the subparts.


COMPLEXITY AND PLEIOTROPY

Pleiotropic effects -- in any complex system -- are intrinsically minimized
by modular partitioning of the subprocesses. And evolution, as an adaptive
process, has clearly discovered the values attendant to modular code and
partitioned behaviors. Indeed, such structural partitioning is the mechanism
that allows the common phenomenon of "mosaic evolution," an evolutionary
process where one part of the body (such as mandibular morphologies or gut
chemistries) are allowed to rapidly change in response to new evolutionary
pressures while other organs (such as the eyes or feet) remain relatively
unmodified.

Nevertheless, no complex system exists without extensive pleiotropy -- nor
can it be designed out of a system, no matter how extensive the effort. The
best that can be done is to attempt to minimize its effects, but even in that
effort, total success is unachievable.

It is possible to obtain a crude measure of the extent of the pleiotropy that
permeates a specific design. Such a technique is called "sensitivity
analysis" in engineering. Each component in the system is slightly varied.
The extent of the change that ripples throughout the system is then measured
in every subsystem.

Occasionally, a sensitivity analysis becomes a failure analysis. In the case
the Space Shuttle Challenger, the partial failure of a single o-ring gasket
shut down the Challenger's on-board telemetry -- along with every other
subsystem. The Challenger didn't "explode." It suffered a deflagration event
(which in engineering terms, means that it suffered an overpressure wave that
basically tore it apart at its seams). Each major structural subsystem (the
wings, the crew cabin, the main engines) remained more or less intact after
the event. It's just that as a collection of subsystems moving at high speed,
the Challenger lost "integrity," no longer capable of functioning
competitively as a unit whole.

And that's very much the point that Mayr has been trying to make for the last
fifty years when he speaks of the "unity of the genotype." The genotype can
only be assessed and evaluated as a unit whole -- if for no other reason than
because that was the context in which the genotype was evolved and optimized.


POLYGENY AND PLEIOTROPY

Five thousand to 50,000 actively translated gene products are characteristic
of metazoan genome sizes. On average, 10-50% of the active genome appears to
be translated in any one cell type. Constituent code representing basal
cellular metabolism (commonly called "housekeeping code") appears to
represent 50-75% of the code translated within all cells (10,000-20,000 gene
functions in Deuterostomes). Much of this basal constituent code is presumed
to be not characteristic of the species, but of the phylum, or higher,
indicative of the antiquity of its origin. Tissue-specific code (another
10,000 to 20,000 gene functions in mammals and birds; often called "luxury
code") is evolved hierarchically on top of the basal genetic platform.

Nonetheless, the complexity of a metazoan phenotype appears to be far greater
than the complexity of its genome. The simple mechanism that permits such
excess complexity to be evolved is the re-use of code.

The construction of all complex, well-conserved structures (an eye, a heart,
or stereotypical behaviors) result from the polygenic expression, directly or
indirectly, of virtually all of the translated genome. To speak of a "gene"
for a complex behavior such as altruism, monogamy, or "uncapping" is simply
nonsense and cannot be justified even as a verbal shorthand. It is, at its
core, completely misleading.

The first to clearly demonstrate the implicit pleiotropy associated with code
re-use was Hans Gruneberg. Gruneberg, a geneticist who did the majority of
his work in the 1930's, used the phrase "spurious pleiotropy" to describe
those pleiotropic effects that permeate much of the phenotype due to the
obvious re-use of code. Gruneberg found that a single mutation in the rat
caused thickened ribs, a narrowing of the lumen of the trachea, emphysema of
the lungs, hypertropy of the heart, blocked nostrils, blunt snout, and low
viability. Congenital medical "syndromes" (literally: symptoms that "run
together") such as these are virtually always the pleiotropic effects of a
single gene's mutation -- and hundreds of similar conditions for humans are
now well known.

Sewall Wright preferred the term "universal pleiotropy," to especially
emphasize the same point that Mayr makes. Change any one gene -- and if that
change is expressed -- then that change will almost certainly have effects
that resonate throughout the phenome. Essentially all modern evidence
suggests that Wright was correct: all expressed genes tend to be universally
pleiotropic. Non-pleiotropic gene products simply don't exist. But that moral
is just as prevalent from all engineering experience, also.

As a simple and more subtle example, consider the genetics that encodes the
mammalian hair protein rope. The hair coat in mammals is used (among other
uses) as: (i) a thermoregulatory blanket, (ii) an armoring coat, (iii) a
mechanism of crypsis, (iv) a conspecific recognitiion mechanism, (v) a water
shedding surface, (vi) an ectoparasite defense mechanism, (vii) as part of an
antifungal, antibacterial mechanism, (viii) an auxiliary mechanical
structure, (ix) as weaponry, and (x) as a pheromone dispersant. If a change
should occur in the code such that a significantly modified protein rope were
manufactured, several (or perhaps all) of these attributes would be affected.
Although this would be a far milder form of pleiotropy than Gruneberg's
example of physiological impairment, it is nonetheless an example of the same
code re-appearing in a dozen or so distinctly differently evolved behaviors,
and thus of pleiotropy.


EVOLUTIONARY INERTIA AND PLEIOTROPY

Ultimately, however, the effects of pleiotropy on the evolutionary process
itself are more subtle and fundamental than merely these simpler effects.
Unchecked pleiotropy within a design has extremely deleterious effects on the
ability of a complex system to be continuously evolved over time. Indeed,
massively pleiotropic systems can't be modified at all -- merely because the
fitness value of the integral whole would be so degraded by the smallest
change. A system that is massively pleiotropic has become a house of cards
and has been made extremely sensitive to change (fragile) as a result.

Thus, the discovery of benefits of modularization, in both code and behavior,
is thermodynamically inevitable, for both engineers and their coding
practices as well as for natural evolutionary processes. Complex systems
cannot be evolved to points of high optimality -- and then re-evolved yet
again under changing circumstances -- if pleiotropic effects aren't
suppressed to the greatest degree possible.

The corollary to this statement is perhaps somewhat surprising: the
minimization of pleiotropic effects through increasing modularizations of
code and behavior operates to greatly accelerate the rate at which
evolutionary optimizations may be achieved, and therefore work to greatly
increase the competitiveness of a phyletic lineage. This single evolutionary
advantage of increased speed attendant to the minimization of pleiotropy may
underlie the totality of the reason for the existence and initial appearance
of distinct organs within multicellular biota, a design schema where such
distinctive organs operate as a complex, co-ordinated unit whole, yet remain
substantially isolated in their behaviors. Such a design plan seemingly
permits the evolution of extremely complex, autopoetic organizations, far
more so than would otherwise be allowed, that can be evolved at much higher
rates than would otherwise be permitted.


HIERARCHY AND PLEIOTROPY

There is a secondary attribute of all complex systems that guarantees
pleiotropic interactions. Pleiotropy is intrinsic to the nature of all
hierarchically layered coding structures, even if code segments (genes,
microsubroutines) remain unreused. All complex systems that were evolved over
time are inevitably hierarchically structured.

Modifications to the root code in such a hierarchy are inherently highly
pleiotropic, simply because the basal code has come, through time, to have a
great many subprocesses be dependent upon its reliable execution. Any
modification to code at the root of the tree shakes the entire dependency
tree. The inevitable result is that the system (the phenotype) is moved off
of its previous point of optimization and its fitness value significantly
degraded.

Terminal modifications (modifications to code and behavior that have no
dependencies) are the only portions of code that can be changed without
expectations of explicit pleiotropic effects. The only question that remains:
can any behavior be truly imagined or designed so that it is absent of all
pleiotropic effects, and thus be truly terminal?

Wirt Atmar

========================================