Fighting Zombies in Your Web App

Getting rid of the unused

Zombies?

Anybody managing a web application knows them, even if they don’t realize it. Zombies. Not the actual blood sucking ones from “The Walking Dead”, but zombie features in your application. These features stay around your app long after they have done their job, and are no longer producing any business value.

Where do these zombies come from? Well, the story usually goes like this: your product manager comes along with a great new feature to add to the app. At first, all is good — the feature is added and users use it. As time goes by, however, the feature may become irrelevant for one reason or another, and users stop using it. In other words, the feature becomes a zombie feature.

Why do zombies matter

Now that we understand what zombie features are and recognize the fact that they exist, one might wonder, why should I care? You could make the claim that this is the PMs responsibility and we, as R&D, can carry on with our lives as long as these zombie features actually work. But unfortunately, it’s just not that simple.

Let’s try to tackle this question and understand the price you’ll pay for maintaining these zombies:

• Larger app means it takes longer to add new features.
  Adding a new feature into existing code usually makes the app more complex, and coding it will just take longer. This means that, the more features you have, the bigger the “fine” you pay when adding new features, in terms of the time it will take to develop them.
• Test execution and maintenance.
  Zombies need to be tested. If testing is done manually, then a price is paid in terms of QA hours, or if testing is automated, then you’ve got redundant test code to maintain. In some cases, test execution comes with fees (for example, when working with tools such as testim.io), so testing zombies has a direct impact on expenses.
• Application usability.
  A complex, large application is harder for a user to use. Removing zombie features makes the app simpler and the users happier as a result.

The challenge: zombie detection

Measuring usage of a capability exposed on a web app is pretty trivial and can be done with several analytics tools, the most famous one probably being Google Analytics (GA).

Why isn’t Google Analytics enough?

• Zombie blind spot. Google Analytics, and other similar platforms, can only know about events that are fired from the app. Zombie features are, by definition, unused and so GA events will not be fired for them.
• Push monitoring strategy. Zombie features are essentially points of failure in an app. So it makes sense to treat zombies in a similar way that we treat bugs. Take this line of thought further, and you end up automating the detection of zombies using a test. As a result, zombie detection will be marked as a test failure. In order to do this, we need more than just a standard analytics tool.

How we detect zombies

We run a periodic “zombie detection” test. This test ensures that all events that a web app expects to be fired in a certain(*) period of time are actually fired, at least a certain number of times(**).

(*) We call this the measurement timespan. This timespan is actually the time it takes for a feature to become a zombie feature. There is no right-or-wrong answer to what this timespan should be and so we settled on 60 days. We plan to add the ability for the timespan to be configured per event (some features are used rarely by nature and have a longer lifespan, whereas some features are expected to be used all the time and deserve less grace period).

(**) We call this the threshold. A feature is considered a zombie if less than X events were fired in the measurement timespan (some features are expected to be heavily used and so they can be considered zombies even if some number of events were detected in the timespan). For simplicity, we started off with the number being 1.

The test flow

1. Fetch all measurable events from the web app (list A). These are all the events the app expects to have been fired. Note that the app is expected to expose a list of all the event names in a form of an API in order for the test to fetch it.
2. Call GA API in order to fetch all events fired in the given measurement timespan. We can extract the number of times each event was received by GA and filter only the ones that passed the configured threshold (list B).
3. Validate that all events on list A can be found on list B. If this is not the case, then the test will fail and log the missing events, indicating the new zombie features detected.

Once zombies are detected, we work together with product management to remove the feature from the app. We also remove the remaining code so no trace i left behind.

What’s the big deal here?

At Outbrain, we strive to write and maintain code that adds actual measurable business value. We call this methodology Impact Driven Development. The reason we are excited about this “zombie detector”, is that by just adding a simple test, it enables us to be much more impact driven when managing our web app development. With this test in place, we can make sure there is no redundant functionality in our app and we maintain old features only if there are users who actually use them. The developers in the team have a constant feel of the user domain and can rest assured that features they push to production will not just end up useless zombies. This creates a much more efficient team, who are connected to the product and its business value.

To sum up

We started by accepting the existence of zombie features and understanding what they are, moved on to why they are unwanted beings in our app, and finally introduced a solution to the challenge: our “zombie detector” test.