Feature Flag Retirement  

Removing Old Flags and Technical Debt

In today’s modern development, you can’t live without feature flags. They allow developers to move faster with less risk. For product teams, feature flags are indispensable because they allow for safe experimentation with new or existing features. Whether for faster feature delivery or continuous experimentation, they unlock better experiences for users while reducing costs and increasing competitiveness for companies.

But, unlike diamonds, most feature flags are not forever. They follow a lifecycle. First, they get created in Pre-Production during the development of a new feature. Later, they’re 100% Released , where they’re no longer needed for the same purpose. This cycle usually happens over the course of several weeks depending on the release frequency of an organization.

A common pain-point among organizations is tech-debt caused by feature flags that have reached the end of their life cycle. If feature flags are not removed from code once they’ve reached the end, their presence causes several issues:

• For one, every feature flag makes the code a tiny bit harder to read, understand, and maintain. The reason for this is because feature flags add a level of complexity to the code. Developers waste time trying to understand dead code (i.e. code that never gets executed) when they’re dealing with code that contains flags that are 100% Released.
• Even if a feature is 100% Released and turned on for customers, sometimes not all of the tests are updated to be in the On state. Furthermore, sometimes new tests fail to add the feature flag which will put them in the Control or Off state by default. So new tests could even be testing the Off state. This means that the tests aren’t actually testing the same code that customers are using. In this scenario, a bug could be introduced without being noticed, despite strong test coverage.

There is an easy way to identify which feature flags can be removed from code. Simply look for ones that have been in 100% Released status for at least 100 days. Once these flags have been identified, their owners can be informed to remove them from code. The Split Admin API is perfectly suited to automate this process via a script. Let’s dive in!

How Split Can Automate Removal

First, the List Splits endpoint is used to list all flags in a certain Workspace. Expect the endpoint to return this response:

{
    "objects": [
        {
            "name": "sample_feature",
            "description": "A sample feature to help you learn how split works.",
            "id": "0000cea0-8f4d-11e7-b345-491559441642",
            "trafficType": {
                "id": "6414eaa0-8f4d-11e7-b345-124259445f48",
                "name": "user"
            },
            "creationTime": 1504294821336,
            "tags" : [{ "name": "one tag" }],
    "owners": [{
                    "id": "ff88ac00-ee89-11ec-adf2-72d3f125aefe",
                    "type": "user"
                }],
            "rolloutStatus": {
                "id": "35f71d79-0cb1-42d4-b029-5e5468c480e1",
                "name": "100% Released"
            },
            "rolloutStatusTimestamp": 1625668535289
        }
    ],
  …
    "offset": 0,
    "limit": 20,
    "totalCount": N
}

Next, the script needs to filter the response for splits that are in rolloutStatus 100% Released. The script also needs to make sure that the splits have been in that status for at least 100 days. Comparing the rolloutStatusTimestamp with the current timestamp will achieve that. For each of the splits in this filtered list, the owner id needs to be used as the input for calling the Get User endpoint. This endpoint returns:

{
        "id": "<user_id>",
        "type": "user",
        "name": "<display_name>",
        "email": "<email>",
        "status": "ACTIVE",
       …
}

The email address in the response above can be used to reach out to the owner of a split that is ready to be retired.

Another way to find out which feature flags may be removed from code is via the Rollout Board in Split. The Split Team recently added a view called Ready to cleanup. This view will only show flags that have been in one of these statuses for at least 100 days: 100% Released, Removed from Code, Ramping, Killed.

There are plenty of ways Split helps you to take care of tech debt caused by feature flags. And, we’re just getting started! Stay tuned for more help & automation to clean up flags in 2023.

Ready to get going with Split? Begin your free trial.