Emergent Design is frequently likened to the process of evolution. Proponents speak of "evolving a design" , the implication being that some software equivalent of natural selection is weeding out the inferior mutants, leaving only the fittest to survive. If this is the case, why have the three classes above not evolved into a better design? Or is that evolution
yet to occur? Or are these three classes actually the fittest to survive already, for some suitable definition of "fittest"?
I conject that the practical application of Emergent Design so constrains the evolution of the design elements that we cannot expect such an approach to have a reasonable chance of giving rise to a good design.
Comparing the evolution of a software design with the evolution of a species, we see the following significant differences:
• Evolution can take its time exploring as many dead ends and genetic cul-de-sacs as it likes. There is no supervising authority standing by looking for visible signs of monotonic progress. There are no time constraints or fiscal limitations that require evolution to produce a workable result within a certain number of generations.
• Evolution can explore many alternatives in parallel, but a development group will rarely have sufficient resources to try a large number of different design alternatives in parallel. A very limited number of resources assigned to a design task must try alternatives in series, if at all. Obviously there is a strong tendency to stick with the first one tried that appears to hold promise.
• Evolution is objective in its evaluation of the success of each alternative. There is no attachment to a genetic alternative that is nearly good enough. However software developers often favor "pet" design approaches, or try and force non-optimal designs further than they should go because there is the promise of success just around the corner, and the attendant resolution of an uncompleted task. That is to say, it is very human to normalize deviation.
• Evolution is not required to be predictable. No one has bet their financial future on the lesser fairy penguin evolving heat dissipation mechanisms to cope with increasing Arctic temperatures, and doing it in no more than 3 generations. But stakeholders in software development efforts will commonly invest large sums to see successful designs produced (and thereby business problems solved) within a limited contract period.
You will find any number of elegant analogies in the Emergent Design literature – but finding one that addresses the above constraints is quite another matter.
For example, there is the delightful story (probably apocryphal) of the landscaping engineer who was asked to cement pathways at a University,
after the buildings had been erected. Rather than predict the correct place to put the pathways, the engineer stood back for one semester and let the students make their own way between buildings. The furrows they wore in the ground were adopted as the courses for the cement pathways.
How very Zen... really, it's a terrific tale. I love it. But before we spin our prayer wheels and marvel at the engineers’ wisdom, let’s think of the liberties that the landscape engineer was allowed in pursuing such a solution method. Liberties which would be denied a great many University contractors in the real world:
• The landscape engineer was allowed to take the time necessary to wait for the paths to emerge. What if the University had required completion sooner than that – say, before the semester started?
• The landscape engineer was allowed an entire semester in which he was not required to demonstrate visible progress. What if a competitor had taken advantage of this lull and offered to complete the job using best guesses of the correct routes for the pathways.
• The landscape engineer was free to distribute the labor and materials cost over the course of the project as he saw fit. What if the budgeting system of the University had made allowances for expenditure on landscaping in this semester, but not in the following one?
• An entire University cohort spent a semester walking through the mud after every rainfall. They were willing to put up with this discomfort so that the engineer could let his design emerge. I wonder how the senior lecturers felt about this. More importantly, I wonder how those students in wheelchairs coped.
Emergent Design has the capacity to lead to some very elegant solutions – eventually. That design may be wonderfully efficient – if you have the financial stamina to await its arrival and the confidence that you will recognize it when it appears.
Conclusion
Does Emergent Design work? Of course - just look in the mirror. You and every other product of evolution is testament to the potential success of the approach.
While the idea has aesthetic appeal, the practical context in which the emergence occurs makes all the difference. The requirements for timeliness and predictability in a software development project, together with the subjective nature of those who gauge the cost/benefit of a particular approach, mean that true, uninhibited evolution cannot occur. If the compromises embodied in an emergent design are consistent with our corporate priorities, then it will be by coincidence only – and that’s too important a matter to leave to chance.
* First published 14 Oct 2003 at http://www.hacknot.info/hacknot/action/showEntry?eid=29 1 http://www.adaptionsoft.com/xp_practices_simple_design.html
2 Extreme Programming Refactored, M Stephens and D Rosenberg, Apress, 2003 3 http://xp.c2.com/DoTheSimplestThingThatCouldPossiblyWork.html