Skip to content

Evolution Doesn’t Do Design

I was contemplating why we as humans design things in order to create the new and the better versions of what we have. It doesn’t seem to fit very well relative to nature which will tend to use chance and filter the good results. Evolution doesn’t do design.

So an inquiry into what this means for SaaS (Software as a Service) application design is interesting to me. You could argue designing improvement is a less effective mechanism than filtering a pile of chance results. This is a little scary for someone like me who really appreciates design. After all it is only a single or limited input mechanism. The realm of knowledge an individual has in their specific context is very limited. Even a group has limits. Relatively it is very small when you compare to the enormous test and release environment that the natural world has for it’s many species mutations.

australian_sea_eagle.jpg

You could say that every creature inputs their genetics into the natural process of evolution to be tested. A candidate for better or worse genetics. Accordingly there is has been spectacular results like the evolution of the nervous system, interdependence of creatures and my favourite the symbiotic relationship.

Evolution puts species through continual survival testing. Successfully featured creatures survive and the poorly featured creatures are killed off, never to be cloned again. The reward is simple and pure. The right to pass down your design and increase it’s spread. Mutations allow change, often radical. They are a very low cost chance of improvement. Near free options on evolutionary upside. Physical and behavioural mutations that are beneficial lead to higher probabilities of survival and a new creature is born.

If SaaS evolved and wasn’t designed what would happen?

So I’ll bring this back to the area I understand, SaaS (Software as a Service). If Mother Nature were a SaaS developer she would probably just add features like mutations over and over and keep killing them off if they didn’t work as improvements and leave them when they did.

If customers used a new feature mutation then mother nature would be rewarded with dollars. So does this imply customers could be left to control the development by their evolutionary wallet. Well the answer is yes if you are happy with a slow kind of evolution.

So why is this less than perfect when it seems so so right? The answer is in luck. Genetic mutations for the sake of this argument could be considered natural luck. Some mutations are very lucky advantages while others are a fatal blow.

Accordingly a SaaS developer can choose to enhance development with customer feedback and also with mutations. Those things the customer never dreamt of. Things that need survival testing. Injecting new ideas or concept into the SaaS application gets accepted or rejected by the customers wallet. The ultimate survivability test.

An amazing market advantage is only ever one left field mutation away. One feature that so alters the customer experience that it might never have been perceived through customer voting systems or looking at competitors.

Evolution has leaps like this. Mutations that lead to one species dramatically outcompeting another. Many individuals in the species will evolve from the single creature feature that was so advantageous. Quite efficiently the cost to get this big upside is only ever single individuals whose mutations didn’t work in their favour.

So it might take several mutations to find a very successful change but when it hits it takes off in a large way. It even leads to the extinction of related species. When you repeat this process with velocity you can quickly see why natures model for improvement should not be overlooked and that maybe designing a little too much might miss the evolutionary leaps.

2 Comments

  1. I think that the evolutionary principle is very much at the heart of agile development methodology – get new features “out into the wild” and see what sticks. Sometimes things work, sometimes you’ll need to roll back.

    I think there’s one core issue though – how do you determine what “survives” or not?

    Once a feature has been released, someone, somewhere will find use in it – so it’s hard, then, to remove that feature without disenfranchising your customers. The bigger your user base, the harder it is.

    The other, related, thing is that it’s easy to keep adding feature after feature, gradually expanding things until what’s evolved is a great fat hairy monster with 8 ears and 5 arms and a technicolor fur. So it can evolve into a bloated bit of software that then gets too heavy and dies a slow and painful death in the market.

    The evolutionary process occurs through competition in this model – many different companies trying very different things and the one that gets it right (mostly) survives. So it’s important, then, to think really hard about what gets added – to make sure that, on balance, the next evolutionary step will provide enough value to give you the evolutionary edge, without falling into the tar pits of bloat.

    And that’s really what “design” is all about. The techniques of design help to understand what is of most value to the customer so that as the software evolves, it remains lean and fresh and ahead of the competition.

    (Of course I’m talking about design in the broader sense – interaction, experience, information architecture etc. – as well as visual)

    Posted on 20-Oct-07 at 10:28 am | Permalink
  2. Totally agree. I think our only difference is the target market. I’ll post my thoughts, I started writing a comment but it got a bit long.

    Posted on 22-Oct-07 at 9:32 am | Permalink

Post a Comment

Your email is never published nor shared. Required fields are marked *
*
*