Ship it switched off

Think of it when you want new code live but not yet visible, or you want an off switch for a risky change.

In everyday life

A restaurant prints a new dish on the menu but covers it with tape. The owner uncovers it at one table first, and can tape it over again in seconds if the dish goes wrong, without reprinting the menu.

One case

A bank app’s new transfer screen goes live at 09:00 behind a switch, turned on for 5% of users. Within minutes, 1 in 10 transfers on the new screen fails. At 09:44 the team turns the switch off. Within seconds, everyone is back on the old screen, with no new release.

The switch limited the bug to 5% of users for 44 minutes
The case, cell by cell1 cell = 10 minutes
Transfers that fail on a usual day
0.1%0.1%0.1%0.1%0.1%0.1%
Transfers that fail today
0.6%0.6%0.6%0.6%0.3%0.1%
Users given the new screen
5%
New releases needed
0
Failures across all users: 5% of users on the new screen, 1 in 10 of their transfers failing. The switch went off at 09:44.

Every case

A flag separates two events that used to be one: code going live, and users seeing it. You can put unfinished work live safely, show a change to 1% of users first, and turn it off, usually in seconds, if it misbehaves. That is much faster than a new deploy. The cost is a second path through the code. A flag left in place after the rolloutTurning a change on for more users in steps, such as 1%, then 10%, then everyone. is finished is clutter that nobody tests.

The word

Engineers call this

feature flagA switch in settings that turns one piece of new code on or off without a new deploy. The code goes live switched off; then you turn it on for some users, for all, or for none.

Put risky changes live switched off, turn them on in steps, and keep the off switch until you trust the change. Delete the flag when the change is fully on.

Where this idea leads