Evolution versus Revolution

A friend of mine once, as part of a job application, had to do a presentation concerning evolution versus revolution and how they applied to software. For one reason or another she never did the presentation, which was lucky because as she confessed to me she didn’t know what to talk about.

If you had a big piece of software that needed changing so as to keep up with your competitors, whilst also allowing you to introduce new innovations, which method would you choose? Would you sweep all the old code to one side and start again with a completely clean sheet: the latest technologies, perhaps that new language that everyone is raving about and commit all your development resources? Or would you take calm measured steps, always aware of the direction you needed to go in but conscious also of the here and now, the code you currently have, the demands of business and your customers?

Is the Big Re-write really a revolution? Netscape thought so but in the three years it took them to develop the latest version of their browser the market and their customers had moved on. At a previous company two well-meaning developers were given a year to develop a brand new product, the company stopped taking on any new business and we all waited. At the end of the year, the product was half-finished, difficult to work with and within the next year was already being replaced.

Revolutions happen swiftly and suddenly. Something that takes three years cannot be a revolution but that doesn’t imply it is then evolution. Evolution is when you adapt, when a tangent suddenly turns out to be an exciting new direction. When a caterpillar turns into a butterfly that’s evolution, when a potato goes mouldy that’s decay; both have changed but only one for the better.

The tricky part for developers is writing software and applications that give us this flexibility, this ability to evolve and keep our companies in business

I believe that Agile development, Object Orientation, and lean, well- tested code give us this flexibility. Growing object orientated code is evolution, and if you’ve read the book then hopefully you’ll agree with the point I’m making. If you have’ a big piece of software’ make gradual changes. Re-write a bit at a time. Do some pruning; get rid of repetition or redundant features. Set small goals and aim to achieve them quickly. Get these changes out into production and see what happens. Don’t wait around. That’s evolution, just getting on with things.

Getting rid of everything that’s gone on before and starting again is tempting but is that really possible with software? Don’t forget that revolutions could also mean you are simply going around in circles, repeating the same mistakes many others have made before.