The concept of survivorship bias in software engineering isn’t new, but have you heard of Zombie Bias? In this post I’m going to explain what Zombie Bias is, and why developers need to be on the lookout for it in their teams. 

What is Zombie Bias?

I’ve often noticed while working as part of a team – particularly teams who have a lot of history together – that as time goes on, and code builds up, developers and engineers start to spot issues that (with hindsight) would benefit from some improvement. 

Sometimes we identify a piece of code that could be better, and make the improvements it needs. When it’s done we forget about it. Other times we see flaws but don’t address them in the moment, either because of time constraints and other priorities, or because that deficiency isn’t causing significant problems. As time goes by we tend to forget about the  things that we corrected, and instead fixate on the things that we didn’t. This is what I like to call Zombie Bias. It’s looking too hard at the bad things that survived when they shouldn’t have, at the expense of celebrating how many horrors we did get rid of.

This is a form of survivorship bias, but I think putting a different slant on the ‘bad’ code that survived highlights a crucial opportunity we sometimes miss. The team over-fixates on the problems that didn’t get fixed (the bad code that survived) while forgetting about the problems that were fixed (the bad code that didn’t survive). Zombie Bias is what happens when our thinking is dominated by code that shouldn’t have survived, but did – the Zombie code. 

Why it’s not code, but Zombie Bias that needs fixing

Why is Zombie Bias a problem? Because it affects morale. Teams develop a feeling of code decay; they conclude that the code has deteriorated over time, perceive that their maintenance work is sub-par, and become demotivated.

As a piece of work grows, and code imperfections accumulate, I’ve seen teams develop a kind of collective guilt where all they see is what’s wrong, forgetting all the positive actions they’ve taken on their way to creating and finessing a product. The mood can even cause teams to despair over an entire product’s viability, and feel compelled to abandon the work and start from scratch. 

So what’s the solution to Zombie Bias?

The important thing here is not to take it personally. Those code inferiorities didn’t happen because we’re bad developers, but because we made smart trade-off assessments about priorities. They’re things we decided to live with because other things were more important. The trick is to learn to live with them without guilt.

It’s easy to forget about the things we do achieve, and I think there’s a lot of value in making these positive moments visible, as a constant reminder of the good work we do. During any prolonged piece of work there will be fluctuations in success, and times when things look less rosy. Wouldn’t it help on those occasions to remember that things aren’t as bad as they would have been without all the work we’ve already done? 

The heavy weight of perfectionism

For us at Equal Experts – a company known for our expertise – it’s important to define what Expert means. Does being an expert mean executing every tiny detail perfectly, or does it mean that we understand what good looks like? I think the ‘expert’ in our business involves knowing when something needs to be improved, and when it is good enough. It’s being able to create excellent solutions for our customers, without getting bogged down in superfluous perfectionism that delays results and drags down motivation. 

As an innovative business we focus a lot on the possibilities; we’re well-known for thinking outside the box to find better ways of doing things to deliver business value for our customers. The challenge for us comes when we see a possibility and decide not to pursue it. That’s when anxieties can kick in over whether we’re doing enough, creating the best product, being the best. I believe that doing the best thing sometimes means actively deciding to reject a possibility, and being okay with that. 

Ta-Dah!, not To-Do

Someone once told me how their to-do list got them down every day. How fed up they felt when they inevitably didn’t achieve everything they’d told themselves they must, and had to carry it all over to the next day. One day, instead of a long to-do list, they made a Ta-Dah! List, writing down everything they’d done, in real time (including cooking a healthy lunch from scratch, and walking the dog). Their motivation at the end of that day was much higher, from focusing on all their accomplishments, than it had ever been from looking at all the tasks that still hadn’t been achieved. 

Now, I’m not saying we should ignore the fundamental work that needs our attention, and there is value in a list of priorities. But wouldn’t it be great if we could let those priorities guide us in a forward-thinking way, whilst always keeping one eye on the great work we’ve already done? 

This could take the form of a diarised get-together – once a month, or at specific points in an engagement – where we proactively look at the work we’ve done, not from a ‘what’s outstanding’ point of view, but to celebrate and remind the team of how much they’ve achieved. Or maybe it’s a regular update to a team Slack channel where we take the time to notice what’s been done, and the effects of that action. Perhaps it’s even as simple as taking a moment to recognise a piece of work for ourselves, and the value it brings. If we develop a habit of mindful acknowledgement – for ourselves, and within our teams – who knows what it will do for morale and motivation, as well as product sustainability?

Has this struck a chord with you? Share this post with anyone you think needs to read it.