The application you are working on
will be rewritten.
Twice, probably,
in a language that is not yet
anybody's default,
by people who will not know your name.
The rows will survive all of it.
The customer record created in 2011
is still there.
It has been through three frameworks,
two databases
and one migration
that everybody remembers badly.
It will outlive the next rewrite too.
Which makes the schema you sketch
on a Tuesday afternoon
the longest lived thing
you will produce this year,
and almost certainly
the least reviewed.
Here is how it goes wrong,
and it is never dramatic.
You store a status as a number.
Nought is pending, one is active,
two is something that got renamed
in a meeting in 2019,
and the only place
those meanings have ever existed
is a class in the application.
Delete the application
and you have a column of integers
with no dictionary.
Or you store a timestamp
with no time zone in it,
because the server was in one place
and it seemed obvious at the time.
Or you keep a serialised object,
readable only by the exact version
of the exact library
that wrote it,
which is a fine arrangement
right up to the morning
that library is gone.
The test is not whether it works today.
The test is whether somebody
in fifteen years,
holding this data
and none of this code,
can work out what it means.
That is not a romantic question.
It is the question every migration asks,
every acquisition asks,
every regulator asks,
and every rewrite asks
in its third week
when the nice plan stops working.
So write the meaning down
where the meaning lives.
Real dates, stored as dates.
Statuses that spell themselves.
Units in the column name.
A note somewhere durable
about what each table is actually for.
And keep at least one path
to your own data
that does not go through your own code.
Programs are opinions.
Data is the record,
and the record is what gets inherited.
– Serguey Asael Shinder
