Zombie code: the ghost that bites you.


My thanks goes to Julian Sims (web site http://www.bbk.ac.uk/management/our-staff/academics/sims-julian, twitter @juliansims) for prompting me to write this post.


Julian and I had a long and wide-ranging discussion on Twitter about some of the causes of the recent disasters experienced by banks when it came to delivering services to their customers. Examples include the Lloyds Banking Group and Bank of America. This was underpinned by Leo Kelion’s article entitled “Why banks are likely to face more software glitches in 2013” which examined the causes of such events. One of the key phrases in that piece is “dead code was brought back to life”. This is often known as “zombie code”, hence the title of this post. The problem with such zombie code is that it was created for another age – it is much the same as asking a stagecoach driver from 1750 to drive a modern day Ferrari: the result is guaranteed to be a disaster.


Julian and I were were tweeting each other about possible causes of zombie code, and one of his tweets “@philhart in the UK Aspergers is labelled ‘learning difficulty’ rather than ‘learning specialty’ – could that be part of the problem?” jolted my thinking out of its usual ruts. My short answer to that question is “No”, but that answer needs justification.

Before I go too far, I should mention that Asperger syndrome covers a range of symptoms, one of which includes “Intense preoccupation with a narrow subject” (Wikipedia, accessed 3 February 2013). It is entirely conceivable that this would manifest itself in the way such an individual would write software. I have seen examples where software writing was done in such a way that it was obvious that the software writer had an intense preoccupation with over-applying a particular design style. It is not obvious to me how the software writer’s style would have been influenced by his educators’ use of the labels “learning difficulty” or “learning specialty”.

Once a piece of software has been written and properly tested, it will continue to do the same thing forever, regardless of whether or not its author had Asperger syndrome. We now need to look at the business context in which this happens. Business rules change over time, and financial products come and go. In particular, a new financial product with a strong resemblance to a previous financial product can arise. The key point here is “a strong resemblance”, meaning that it is not identical. In particular, there is something different, and the piece of software that worked correctly for the old financial product is not guaranteed to work with the new product: it has been resurrected, and has turned into a zombie.

By way of a thought experiment, imagine that “cash account” has been changed into a “ready cash account”, and with a change to at least one of its rules, such as what happens when an attempt it made to go overdrawn. It is a new product, but the decision maker, usually somebody high up the organisational tree, is unaware of its impact on the piece of software that is about to become a zombie. The individual responsible makes the assumption that the old software will work correctly with the new financial product. The behaviour of the piece of software then becomes undefined. At the lowest level, cash could simply disappear – this would be picked up by an internal audit and rectified, and the general public would be none the wiser. At the other extreme, it can cause the whole system to crash, and everybody knows about it.

To the Future

Re-casting Leo’s words, I think it is something that we may need to learn to live with. 🙁

One thought on “Zombie code: the ghost that bites you.

Leave a Reply

Your email address will not be published. Required fields are marked *