The concept of survivorship bias in software engineering isn\u2019t new, but have you heard of Zombie Bias? In this post I\u2019m going to explain what Zombie Bias is, and why developers need to be on the lookout for it in their teams.<\/p>\n
I\u2019ve 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.<\/p>\n
Sometimes we identify a piece of code that could be better, and make the improvements it needs. When it\u2019s done we forget about it. Other times we see flaws but don\u2019t address them in the moment, either because of time constraints and other priorities, or because that deficiency isn\u2019t causing significant problems. As time goes by we tend to forget about the\u00a0 things that we corrected, and instead fixate on the things that we didn\u2019t. This is what I like to call Zombie Bias. It\u2019s looking too hard at the bad things that survived when they shouldn\u2019t have, at the expense of celebrating how many horrors we did get rid of.<\/p>\n
This is a form of survivorship bias, but I think putting a different slant on the \u2018bad\u2019 code that survived highlights a crucial opportunity we sometimes miss. The team over-fixates on the problems that didn\u2019t get fixed (the bad code that survived) while forgetting about the problems that were fixed (the bad code that didn\u2019t survive). Zombie Bias is what happens when our thinking is dominated by code that shouldn\u2019t have survived, but did – the Zombie code.<\/p>\n
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.<\/p>\n
As a piece of work grows, and code imperfections accumulate, I\u2019ve seen teams develop a kind of collective guilt where all they see is what\u2019s wrong, forgetting all the positive actions they\u2019ve taken on their way to creating and finessing a product. The mood can even cause teams to despair over an entire product\u2019s viability, and feel compelled to abandon the work and start from scratch.<\/p>\n
The important thing here is not to take it personally. Those code inferiorities didn\u2019t happen because we\u2019re bad developers, but because we made smart trade-off assessments about priorities. They\u2019re things we decided to live with because other things were more important. The trick is to learn to live with them without guilt.<\/p>\n
It\u2019s easy to forget about the things we do achieve, and I think there\u2019s 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\u2019t it help on those occasions to remember that things aren\u2019t as bad as they would have been without all the work we\u2019ve already done?<\/p>\n
For us at Equal Experts – a company known for our expertise – it\u2019s 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 \u2018expert\u2019 in our business involves knowing when something needs to be improved, and when it is good enough. It\u2019s being able to create excellent solutions for our customers, without getting bogged down in superfluous perfectionism that delays results and drags down motivation.<\/p>\n
As an innovative business we focus a lot on the possibilities; we\u2019re 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\u2019s when anxieties can kick in over whether we\u2019re 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.<\/p>\n
Someone once told me how their to-do list got them down every day. How fed up they felt when they inevitably didn\u2019t achieve everything they\u2019d 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\u2019d 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\u2019t been achieved.<\/p>\n
Now, I\u2019m not saying we should ignore the fundamental work that needs our attention, and there is value in a list of priorities. But wouldn\u2019t 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\u2019ve already done?<\/p>\n
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\u2019ve done, not from a \u2018what\u2019s outstanding\u2019 point of view, but to celebrate and remind the team of how much they\u2019ve achieved. Or maybe it\u2019s a regular update to a team Slack channel where we take the time to notice what\u2019s been done, and the effects of that action. Perhaps it\u2019s 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?<\/p>\n
Has this struck a chord with you? Share this post with anyone you think needs to read it.<\/p>\n","protected":false},"excerpt":{"rendered":"
Find out why Zombie Bias tells you more about your team\u2019s morale and productivity than the traditional view of survivorship bias in software engineering. And what you can do to combat it. <\/p>\n","protected":false},"author":45,"featured_media":11320,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"content-type":"","inline_featured_image":false,"footnotes":""},"categories":[5],"tags":[300],"location":[397],"class_list":["post-11318","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-our-thinking","tag-zombie-bias"],"acf":[],"yoast_head":"\n