uuid: - value: 8be3d8d9-4e73-49db-93a6-83349ac1af05 langcode: - value: en type: - target_id: daily_email target_type: node_type target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7 revision_timestamp: - value: '2025-05-11T09:00:18+00:00' revision_uid: - target_type: user target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849 revision_log: { } status: - value: true uid: - target_type: user target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849 title: - value: 'Feature flags should be short-lived' created: - value: '2024-03-11T00:00:00+00:00' changed: - value: '2025-05-11T09:00:18+00:00' promote: - value: false sticky: - value: false default_langcode: - value: true revision_translation_affected: - value: true path: - alias: /daily/2024/03/11/feature-flags-should-be-short-lived langcode: en body: - value: |

Today, I posted a tweet with a screenshot of some code.

When previously working on the Versa CLI tool, I had a TODO comment saying "What if there are multiple languages?".

Versa is a tool for standardising commands between different languages and frameworks, but some projects, like my personal website, use multiple languages.

The website is powered by Sculpin, a static site generator written in PHP (so there is a composer.json file) and node to compile the front-end assets (so there is also a package.json file).

What Problem Am I Trying to Solve?

Depending on the language, commands like versa install will need to execute a different command - e.g., composer installornpm install` (or an equivalent node package manager).

I added PHP support first, so if a composer.json file is found, the PHP command is run as the default.

What I thought was for projects with multiple languages, to prompt the user to select the language when running the command if no explicit language is set.

This led me to do a spike of using Symfony Console's choice method to see what that would look like so I could add a screenshot to the GitHub issue.

Once I'd finished with the spike, rather than deleting the code, I wrapped it in an if (false) condition so it wouldn't be executed, but I could still re-enable it in the future.

The screenshot in the tweet showed this, along with the text "Minimum viable feature flag."

This is only supposed to be there for a short time until I revisit the code and implement the feature I was spiking on.

If it would be a long time before I looked at it again, I'd take a different approach.

Here's the Thing

One of the main rules of using feature flags is that they should be short-lived.

It's less than ideal to read through a codebase and see it scattered with feature flags that are no longer needed and were used to release a feature several months ago, but the flag hasn't been removed.

A feature flag is a temporary solution for separating the deployment of code from the release of a change.

Once it's been released, the flag should be removed.

format: full_html processed: |

Today, I posted a tweet with a screenshot of some code.

When previously working on the Versa CLI tool, I had a TODO comment saying "What if there are multiple languages?".

Versa is a tool for standardising commands between different languages and frameworks, but some projects, like my personal website, use multiple languages.

The website is powered by Sculpin, a static site generator written in PHP (so there is a composer.json file) and node to compile the front-end assets (so there is also a package.json file).

What Problem Am I Trying to Solve?

Depending on the language, commands like versa install will need to execute a different command - e.g., composer installornpm install` (or an equivalent node package manager).

I added PHP support first, so if a composer.json file is found, the PHP command is run as the default.

What I thought was for projects with multiple languages, to prompt the user to select the language when running the command if no explicit language is set.

This led me to do a spike of using Symfony Console's choice method to see what that would look like so I could add a screenshot to the GitHub issue.

Once I'd finished with the spike, rather than deleting the code, I wrapped it in an if (false) condition so it wouldn't be executed, but I could still re-enable it in the future.

The screenshot in the tweet showed this, along with the text "Minimum viable feature flag."

This is only supposed to be there for a short time until I revisit the code and implement the feature I was spiking on.

If it would be a long time before I looked at it again, I'd take a different approach.

Here's the Thing

One of the main rules of using feature flags is that they should be short-lived.

It's less than ideal to read through a codebase and see it scattered with feature flags that are no longer needed and were used to release a feature several months ago, but the flag hasn't been removed.

A feature flag is a temporary solution for separating the deployment of code from the release of a change.

Once it's been released, the flag should be removed.

summary: null field_daily_email_cta: { }