Telephone +44(0)1524 64544


Changing the Car Metaphor

Fri Nov 13 16:30:01 2015

Of late I have found myself using allegories for trying to explain the complexity of some programmatic processes, projects or problems to people. One of the issues we have is that it is very hard for people to understand the level of complexity involved and it is almost as hard for me to explain it in terms that will be easy to relate.

One of the little stories I like to use is the Changing the Car Metaphor. So we start with this little description. You drive a car. That car works for a few years and then it starts to get worn. Parts become harder to find, wear and tear take over and the car has been superseded in many features. The latest models have a lot more efficiency and far more features and optimised for the latest conditions.

So you buy a new car.

Let's call your software project/business processes that car. Now it differs in a few important ways that we have to make clear. It is a custom car, you cannot just buy a car like it as it was individuality built. Therefore any newer car has to be done the same way, it has to be custom built. All companies have USPs and the most successful are a combination of individual processes and efficiencies. The car is very specific. You also can't just stop using this car as it is the only way you work. But you want to have a new car, your old car is now starting to show its age, so you have one of two options.

  1. You build your brand new car from the ground upwards. You can incorporate all the new features from the start. You can use the best modern approaches. However it will take a significant time to build and you will have to keep your old car until it is ready to completely replace the car you have. It is also costly as you have to maintain an existing car with all the expensive part replacements while you devote resources to building the new car.

  2. You can rebuild the old car to become the new car. This is our refactor of the car. This is the process most companies undertake as we can build new parts in place, element by element, without stopping the car.

Here's the complexity bit for you. How difficult is it to change a wing mirror? It is really easy. On most cars you loosen the cover (removing it from your way), undo the restraining fixings, usually screws or bolts, pop out the mirror, pop in the replacement and then put the cover back after re-tightening any fixings. Easy peasy.

Now do the same job while the car is in motion. Try it while the car drives down the motorway at 70mph or drives through heavy traffic on the school run. Do it from the outside of the car and most importantly don't affect anything but the system you are working on. Don't block the driver’s view and don't hinder the car's progress.

That's the complexity. When we refactor we have to carefully plan and quickly implement and test. We don't get much chance to hold things up and we cannot do it wrong so that it stops the car.

Here endeth the first allegory.

[Don't forget that you can join in this conversation by using the comments form or by tweeting at @shadowcat_mdk]