Evolving an Imperfect Design

I continue to be surprised by suggestions that an entire body of code - one which has proven its ability to survive in the software ecosystem, should be completely disposed of and replaced with new, less "buggy" code. I read another treatise on this recently, and I still fail to understand the logic. Why would humans, with the same human imperfection, suddenly start writing completely bug-free code now? Instead, we should evolve this imperfect design.

As an analogy, consider the human eye. If you look at the structure, what you will find is exactly the opposite of what the typical engineer would expect (and, in fact, exactly the opposite of what exists in cephalopods): the light-sensing portion of rods and cones is actually tucked away behind several neuronal layers, as well as the cell's own nucleus.

Retina's simplified axial organisation. The retina is a stack of several neuronal layers. Light is concentrated from the eye and passes across these layers (from left to right) to hit the photoreceptors (right layer). This elicits chemical transformation mediating a propagation of signal to the bipolar and horizontal cells (middle yellow layer). The signal is then propagated to the amacrine and ganglion cells. These neurons ultimately may produce action potentials on their axons. This spatiotemporal pattern of spikes determines the raw input from the eyes to the brain.

(The image above taken from wikipedia.org, and has been released to the public domain.)

One consequence of this design is that the light-sensing portion of these cells need to be more sensitive in order to process a smaller amount of light, given that this light is filtered. This design has evolved to compensate for a shortcoming in the original design. It was simply more expensive to replace the existing design than to make this modification, in order to achieve phenotypically similar results.

Another consequence is that these nerves must find their way out of the eye, which entails going through the layer of light-sensitive cells. That leads to a blind spot, and the eye can't compensate much for this on its own. Here, another system entirely - the brain - is the compensating agent. This is important to consider, particularly in large enterprises with existing infrastructure.

When you are faced with designs that are less than perfect, throwing them all away is certainly always an option, and often times it will be the most expensive option. So, when considering your software organism, there is always the potential to evolve that system in such a way to compensate or make irrelevant that design shortcoming. There is additionally the option of using system integration to allow another system to handle the compensation. Of course, if your systems are not designed with integration in mind (which is, of course, a shortcoming that additional evolution can address), then your options are limited.

In every case, considering how to evolve software is a complex decision. Yes, completely beginning again is always an option. Evolving the existing software is another option. Compensating with a connected system is another option. In fact, this analogy (the ability of disparate systems to serve as the point of evolutionary adaption) only begins to scratch the surface of the power of integration.

Comments (4)

  1. theCoach says:

    There is a bit of a difference that I think is being elided, although informed by some of the more interesting genetic processes.

    When people talk about a complete rewrite they almost never mean that they will throw the old code away or erase it. Most of the time, they will use new tools, look at the existing code, and then use some of that structure (often times including cut and paste).

    So, this is not really starting from scratch. I am reminded of the occasional use of ‘junk’ DNA, which is really just old programs that were once useful, but have overtime been replaced (maybe liked commented out code???).

    The once useful code lying dormant can by chance be picked up and used again — a sort of crane that creates something new, not completely from scratch, but by a new assembly of previously working building blocks.

  2. C++ guy says:


    Can you link to "another treatise on this recently?"

  3. cjacks says:

    C++ guy: I will look for that link. It was actually something that I stumbled across the other day. It was far from an academic work, so I didn’t bother to archive it.

  4. Brone says:

    Interesting info

Skip to main content