Friday, February 19, 2010

Evolution as Nature's way of doing details

Programmers attempt to deal with complexity by getting the details of a system right. Largely programming is simply creating a system that gets all the details right. That's why we buy software packages - because creating software that gets the details correct is a long, slow and hard process. Test, fix, repeat. We try to make software that is as correct as we can make it within the constraints on resources and time.

Nature, however, comes at it from the opposite angle. In evolution, she takes the scatter-gun approach, like the Monte Carlo simulation method. How many legs are better when you live in trees? What kind of skin? Cold or warm-blooded? Nature is pure pragmatism - we can't guess this very well, so just make a load of similar animals, and see which ones survive. Mutation and cross-breeding combine to produce a never-ending stream of ever-differing versions of the same thing. The best ones survive and reproduce.

Imagine you are trying to make a repair system for a robot. The design route says you spend a lot of research money designing ever more sophisticated repair mechanisms, and pack in replacement and redundant parts. The human body just repairs itself automatically, all the time. Not by some clever design but by a process of elimination - knock out the blood platelet genes and you get haemophiliacs.

Nature has a few advantages over programmers, though. It has limitless resources and a slow-changing set of requirements; the competitors, predators, prey and environment of an organism change very slowly, and there's always more oxygen and more sunlight. Programmers, however, have to determine both the resource allocation and the tests of a system, so that what they give to the customer for a fight-to-the-death with the customer's expectations wins the first time.

Largely, however, programmers will run out of time shortly after working out what the real priorities are, and deliver something with a lower probability of survival. So, I suspect a good strategy when specifying software is to demand a minimum level of stuff by a short deadline, then just before it arrives extend it by an arbitrary amount.

One route that I'm waiting for unit testing to take is that of mutated software - if there is a series of automated tests that cover all the required functionality of the software, then why not leave a few machines churning out modified versions of the code and competing them against each other for survival? A part of the rational brain nags - won't this just create hideous amorphs that pass some unit tests and fail as software? But that would imply that your unit tests lack coverage, no?

No comments: