Have you got zombieware running at your company?

The undead systems quietly draining your budget - and how to kill them

There’s a silent killer in your tech stack. It’s not tech debt. It’s not an undiscovered bug. It’s the project you launched six months ago. Yes, the one that you had the party to celebrate it going live. It’s still running, consuming resources but being used by no one. It’s technically alive, but it’s dead to the business. You’ve created zombieware.

My First Encounter

I worked in one place as a consultant and built a pipeline and dashboard - it was beautiful, a work of art that Da Vinci would have been proud of. We deployed it, everyone high fived and then I left. A year later, I caught up with the team and enquired how it was. They said they had stopped using it and went back to Excel. I asked what they did with the dashboard, someone piped up “It’s still there running but no-one uses it”. It was technically alive but practically dead to the business. I realised that I had created a zombie.

Anatomy of a Zombie

Zombieware isn’t abandonware rotting in a repo. It’s the technically-alive-but-business-dead software actively draining your resources while everyone pretends it doesn’t exist. And the only cure? Stop celebrating builders and start demanding owners.

“Zombieware” - software that is technically alive because it consumes resources but is dead to the business because it delivers zero business value

Zombieware is software that is still alive and running - consuming resources and attention. This in itself is not necessarily a bad thing, however, it creates the illusion of value as it devours resources on your server or cloud bill.

What makes it lethal is that it serves no living purpose. There is no business value for the effort to design, create, deploy and maintain the software. This means that it is:

• technically functional and consuming resources (think: CPU, storage, licences)

• it has no active users or its outputs are ignored

• it has no clear owner responsible for its lifecycle

To be clear, this is not some passive form of tech debt. It’s an active, resource-devouring plague on your organisation’s focus, resources and profit margins. The only cure is to shift from a culture that celebrates building to one that demands ownership and return on investment.

The Silent Tax on Everything

Zombieware isn’t some passive liability, it’s a tax on everything you do. It’s paid in compute cycles, cognitive load and opportunity cost. It’s bleeding you dry and no one - not even Alex from Finance - ever approved the expense.

This tax shows up in insidious ways. Consider two exhibits from my own chamber of horrors.

First, the technical drain. We built an internal API to handle customer verification. It just worked - a model of reliability. So reliable, in fact, that when we shipped v2 and moved on, nobody remembered to kill v1. Two years later, we stumbled upon it, faithfully running in production, ready to serve requests that were never made. The direct resource cost for its dedicated compute and storage was bad enough. The real surprise? The indirect cost of shipping and storing of logs no one was reading was even higher. That’s before you account for the security risk of an unpatched, two-year-old service and the cognitive overhead it placed on any engineer trying to understand our architecture.

But the most blood-draining costs aren’t on your cloud bill, they’re inside your head. We spent a whole quarter building a complex ETL pipeline. It pulled data from three tricky systems, cleaned and dutifully loaded it into our data warehouse every night. It ran flawlessly. Six months later, a curious junior engineer asked which dashboards were powered by those tables. The answer? None. The business stakeholder who requested the data had changed roles and their replacement had no idea it existed. The build cost was immense, the ongoing compute cost was in the thousands daily and a total waste, but the real damage was to morale. Nothing kills a builder’s spirit faster than seeing their work become pointless.

These aren’t isolated incidents. They are symptoms of a culture that celebrates the launch over the lifecycle. Let’s be honest: building is the glamour work. Shipping new things gets you promoted. Maintenance is the work nobody sees. The creates an environment that breeds zombieware.

You know how hard it can be to get money to budget or for spending approval. However, zombieware is a cost to your organisation that no one approved. It’s paid in compute cycles, in maintenance overhead, in cognitive load of engineers and in the opportunity cost of what you could be building instead. It’s bleeding you dry, one server instance and one artefact at a time.

The Cure: how to prevent and remove zombies

The first step is instrumentation.

Without the telemetry of what exists and how it’s being used, we are flying blind against the zombie invasion. As we’ve seen in the films, this doesn’t end well.

The second step is clear ownership.

Every new project, from a single script to a microservice, must have a named owner before a single line of code is written. This sounds insultingly simple. It is. Often, it’s the lack of accountability that drives zombies. Ownership isn’t about building - it’s about the entire lifecycle, including decommissioning.

The third and final step is to set a kill switch.

Teams often measure technical metrics like CPU utilisation and service latency. These are important but only half the story. Define metrics up front to measure minimum acceptable usage.

• How do we define usage? e.g. opening a page, clicking a button, making a decision, resource cost

• What time period makes sense? I’ve found that 14, 30 or 90 days are good starting points depending on the situation

• Add the review of the metric to an existing process. If the minimum acceptable usage isn’t hit, undeploy the software

Sound extreme? It’s less extreme than paying for servers to run code that delivers precisely zero value. You already do this with feature flags and A/B tests, you’re just applying the same ‘prove your value or die’ logic to the whole software lifecycle.

Advanced Zombie Hunting

Those three steps will help but zombies are notoriously difficult to kill. It’s often easier to turn a blind eye to the zombie feasting on your cloud bill than rally the team to do something about it. Here are a few ‘gotchas’ that can help stop you from being caught out.

Related systems

It’s not always so simple when many software provide or read information from other systems. If our system is a building block for a downstream system that is important, then we need to consider if everyone is using the same approach. Otherwise, we risk continuing to run our service to feed a downstream system which has no real usage - meaning that our service, despite it’s appearance, is actually zombieware.

Run a Zombie Purge

While the kill switch is great, sometimes we see metrics that are too easy or not measuring the real problem. To solve this, once a year, ideally near October 31st, have the team dress up in Halloween costumes. Spend the day reviewing the usage of all software and doing a purge of any zombieware identified. Every resource or process should be investigated and tagged as either ‘Ok’ or ‘Zombie’. Think of it as a ‘trick or treat’ and reward zombie kills with lollies (candy) or whatever motivates the people at your company.

• Ask a simple question for every system: “Who uses this and what decision did they make with it last week/month?”

• Use monitoring tools to find things with zero usage

• Create a “Zombie of the Year” award as a fun way to celebrate decommissioning and simplifying the stack

Organ donors

When it comes time to kill a zombie, ensure that you harvest any organs that might be useful. These could be features or components you could reuse or queries that add value. The simplest method we’ve seen here is store them in a shared ‘Organ bank’ repository.

The final stake

Look at the last three things you built. Do you know who uses them today? Do you know when they should die? Or did you just launch them and walk away?

True senior engineering isn’t just about building complex things. It’s about having the wisdom and discipline to kill them. Stop measuring your worth by what you launch and start measuring it by what you have the courage to kill.