Add, move, then remove

Think of it when a field, a table or an API that other code depends on must change its name or shape.

In everyday life

Like a town that renames a street: it puts the new sign up beside the old one, waits until maps and post offices have caught up, then takes the old sign down.

One case

A booking site renames the database columnOne named field in a database table, such as the price of every product. “guest” to “guest_name” at 14:00, in one step. The new code reaches the site’s 4 servers one per minute. A server that still runs the old code asks for “guest” and fails every booking page it serves. For 4 minutes booking pages fail: at 14:00 on every server, then on one fewer each minute.

The rename beat the new code to the servers
The case, cell by cell1 cell = 1 minute
Booking pages that should load
100%100%100%100%100%100%
Booking pages that load, one step
100%0%25%50%75%100%
Minutes of failed pages
4
Servers updated per minute
1
Each minute, one more of the 4 servers got the new code.

Every case

Code and data never change at the same instant. Servers update one by one, phone apps update when users allow it, and other teams read your data on their own schedule. A change made in one step breaks every reader that has not caught up yet. Expand and contract keeps both forms alive while the readers move, so each step is safe on its own and each step can be undone. The last step, removing the old form, waits until a check shows that nothing uses it.

The word

Engineers call this

expand and contractChange a shared shape in three safe steps: add the new form beside the old one, move every reader and writer to the new form, then remove the old one.

Add the new form, move everyone to it, then remove the old one. Never rename something shared in a single step.

Where this idea leads

Skills that encode it

  • to-tickets Matt PocockSequences a wide refactor as expand-contract: add the new form beside the old, migrate callers in batches, delete the old form last.