Organic Simplicity
Organic SimplicityI can just see someone saying the human body is way too complex. Please refactor. -- From SimplicityIsOverRated
There's actually some interesting thoughts lurking behind that disparaging one-liner.
Abstract
Some of the principles adocated by XP (SimplestThing, YAGNI, UnitTest) yield a process of "software evolution" that bears interesting similarities to the Darwinian process of evolution by small, random mutations under the pressure of natural selection.
Restriction of scope
This is naturally not an exact parallel, and the analogy can only be fruitful if we keep in mind first and foremost how the evolution of software is quite different from the evolution of organisms.
Rather obviously, the unit of evolution is the species, whereas natural selection works on individual organisms; this has no parallel in XP, which is primarily concerned with individual software systems.
Also obviously, evolution is (or generally believed to be) a non-directed process, i.e. not one driven by an intelligent designer. In software design, we have the opportunity to plan ahead, learn from experience, and so on.
The analogy only observes that, in XP as opposed to other methodologies, there is a focus on :
I claim that the analogy is useful because it is predictive : i.e., some of the patterns in evolution that can be deduced from the very simple "rules" of Darwinian theory will have parallels in software design as practiced by XP; and some patterns of OrganicSimplicity will yield insights that may be useful in our own practice of designing software systems.
Patterns thus predicted include :
In nature, the notion that, given similar local conditions, similar adaptations will emerge, even if they arise from dissimilar genetic stock. Examples include the multiple evolution of the eye, or mimicry patterns.
In software, DesignPatterns.
PreAdaptation?, or CoOptation?
In nature, the notion that some features that have initially evolved for a given purpose may give rise to features that serve a radically different purpose, just because they 'happened to be there'. This is particularly useful in explaining complex features that can't be believed to have evolved "incrementally"; the lung, which is believed to have once been a bladder for flotation, is a good example.
Do we see this in software ?
EvolutionOfEvolvability?
The notion that some features (particularly of embryologic development) that are selected for in the "normal" sense also enhance the species' capability for adaptation. Thus, modern genes have aspects of "modularity", "genericity", etc., such as the segmented design of insects or human backbones.
In software, the notion that designs that have emerged from cumulative change are more resistant to further change. This is the crucial claim of ReFactoring.
This might be only peripherally related to the main thrust of this page. It occurred to me that, for reasons similar to why fractal dimensions frequently crop up in the "design" of natural organisms, code "evolved" by using XP will exhibit some fractal structure.
Costs and trade-offs
There's an interesting observation about adaptive features of organisms : "adaptive" isn't for ever. We may consider a given body part, say a female ant's wings, to be obviously useful; and wonder why many female ants shed their wings at some point in their lifecycle, since wings are such good things to have.
The answer is along the lines of "cost of ownership", or "maintenance costs"; maintaining functional wings, or simply failing to "recycle" the nutriments provided to wing cells, or even the wing materials themselves, incurs a cost which at some point in an ant's lifecycle may be prejudicial to a more critical function, such as making eggs.
This squares with the notion, apparently congenial with XP, that if a piece of code isn't "pulling its weight" it should be refactored out of existence, not preserved for the sake of its hypothetical later usefulness; or for another example that it's better to just delete code that no one is calling than to keep it in or even comment it out.
AppropriateQuality?
This observation seems somehow related to the previous one, but also distinct.
RichardDawkins once mentioned an interesting anecdote, possibly apocryphal, where Henry Ford, patron saint of efficiency in product lines, had a bunch of Model Ts headed for the scrap yards examined. In all cars a certain part - the radiator, say - was systematically found to have borne up to wear and tear much better than the other parts. Whereupon Ford ordered the quality standards for the radiator production lines to be lowered; the car would cost less to make and wouldn't break down any sooner.
Dawkins argues for a similar economy in the "architecture" of organisms - if, say, a monkey's bones are particularly strong, but the leading cause of death in this species of monkeys is at the hand of a fast predator rather than falling from trees and breaking bones, evolution will - up to a limiting point - favor diverting resources from bone building into muscle building.
We might expect evolutionary software design to yield similar patterns - no one module in a software system will be particularly better designed than others; most will contribute in approximately equal proportion to the overall robustness
Original discussion
The human body is a system that has been "kept simple", as have all living organisms : they all started out as very simple organisms. Then, generation after generation, simple changes were added. Only those changes which made the organisms better adapted to local conditions were kept; as a result, the complexity of the human body is EssentialComplexity, recording a long and varied history of contigent changes in local conditions.
I disagree. The human body (really any currently living organism) is a triumph of IncrementalComplexity?. Nature never refactors - if you end up with a 20-step process due to local maxima along the way, Nature will not produce in the next generation a critter with a 3-step process doing the same thing, even if it is the same result -- Pete Hardie
Yup, I agree with that; I thought I'd said pretty much the same thing. I'm not sure what you are disagreeing with ? With the "kept simple" ? That was sort of ironically meant.
Actually, I was referring to the example of blood clotting - in humans (mammals?) it depends on 2 factors in balance. Remove one, and clotting runs away and blood clots in the veins. Remove the other, and you get hemophilia. Remove both and you get a slightly less-than-normal clotting. If Nature refactored, we'd have the latter method, because it's simpler -- PeteHardie
I don't think that the complexity of the human body relates closely to KeepItSimple in the context of software. Like any two areas of thought, there is some overlap, but I don't think there is much to be gained be the comparison. Software seems very different to me. Also the notion that "Only those changes which made the organisms better adapted to local conditions were kept" doesn't seem quite right: mutations happen all the time, they only are always kept unless they prevent reproduction, right? -- EricHerman
Yes and no. Darwinian theory predicts that mutations which enhance reproductive success spread at a fast rate, and mutations which detract from reproductive success die out. Mutations which are strictly neutral with respect to reproductive success may spread, albeit at a slower rate than beneficial mutations. But to be strictly neutral with respect to reproductive success, a mutation would have to bring about only very small changes, so its effect on overall complexity can be assumed to be insignificant.
I will readily agree that organic evolution and software "evolution" are different, er, beasts. But I tend to think they have an interesting parallel; just as Darwinian evolution insists that "large" changes (such as the evolution of the eye) are brought about by tiny mutations, each of which enhances the survival of the organism, so we insist in XP that complex programs should evolve by the accumulation of small functional changes, each of which enhances business value.
I am definitely not sure that nature "doesn't refactor", as Peter asserts. Nature always seeks the local optimum, to be sure, and will never make a design worse to make it better. Doesn't that apply to refactoring ? Refactorings are defined as small changes that leave the system fully functional; refactorings are not, unless I'm badly mistaken, "changes which make a system nonfunctional, but from which a better and functional design can be reached".
Nature does introduce changes which make further changes easier; Dawkins calls that the EvolutionOfEvolvability?. For instance, the emergence of repetitive design in a great many life forms, which satisfies OnceAndOnlyOnce. The five fingers on our hands, for instance, each have a slightly different shape, but they are not produced by a different set of genes each. They share the same set of "finger" genes, with the subtle differences expressed elsewhere in the "hand" genes.
To grant part of Peter's point, what nature certainly can't do is take a hand with four fingers and a fifth entity that fills the same role as a finger, but is in fact an entirely different structure, and make that fifth structure a "real" finger. (See Gould, The Panda's Thumb.)
EditText of this page
(last edited February 17, 2005)
or FindPage with title or text search