Nobody decides to fall behind.
You just have a release this month,
and the version bump is not urgent,
and the tests pass on the old one.
So it waits.
Next quarter it waits again,
for the same reasonable reason.
Then one day it cannot wait,
because a security notice arrives,
or a library you actually need
requires a runtime you do not have.
And the jump that would have been
an afternoon in March
is now a project with a name
and a slide.
That is the whole mechanism.
Upgrades do not get harder
because software gets worse.
They get harder because
you are no longer moving
from here to the next step.
You are moving across four steps at once,
through every breaking change
in between,
and they interact.
Two versions is a diff.
Nine versions is an archaeology dig.
There is a second cost
that never shows up in the estimate.
While you sit still,
the answers stop applying.
The blog posts describe a flag
your version does not have.
The help you find is written
for people who are ahead of you.
You are debugging alone
in a place the community
has already left.
So make it a rhythm
instead of an event.
A morning every fortnight.
Small, dull, boring,
merged before it is interesting.
Let the build tell you
what is out of date,
and let being out of date
be visible to everyone,
not a private worry
held by whoever remembers.
And when something is deprecated,
believe it the first time.
The warning is not a suggestion,
it is a date
that has not been announced yet.
None of this is about being modern.
Chasing every release
is its own kind of waste.
It is about keeping the distance
short enough that moving
is always a decision you can afford.
The future does not break your system
by arriving quickly.
It breaks it by arriving all at once,
after you have spent two years
not moving.
– Serguey Asael Shinder
Top comments (0)