Nine vendors.
One idea between them.
Nine names for the same field,
nine ways to say it failed,
nine authentication schemes,
nine shapes of streaming response
that all mean
here is the next part.
You will write nine adapters
for one concept,
and it will take you a year,
and the year will not show
in any demonstration.
This is not carelessness.
A layer gets its standards
after the fight,
never during it,
and we are during it.
While a layer is contested,
being different
is not an oversight.
It is the product.
The shape is the lock,
and a vendor who matches
the shape next door
has handed you
a cheap afternoon of leaving.
Mail settled into one protocol
long after it mattered.
Payments took a decade
and are still not done.
This layer has nothing yet,
and nothing is coming soon.
So here is the cost you should plan for.
Your integration code
grows faster than your product.
Every vendor's change of mind
arrives as your incident.
Migration stops being a swap
and becomes a rewrite,
which means you will stay
with a vendor you dislike
for a year longer than you meant to.
And your engineers
accumulate vendor trivia
instead of knowledge,
which expires
when the vendor does.
Own the shape yourself.
Define what the thing means
in your own words,
in your own types,
with your own errors,
and let no vendor vocabulary
past that line.
Write the second integration
before you need it.
Not to use it.
To find out where the first one
leaked somebody else's ideas
into your code,
because it did,
and one implementation
will never show you.
Keep their words
in one file,
at the edge,
where somebody new can read
the whole translation
on a single screen.
The day a vendor changes its mind,
you want the diff
to be that file
and nothing else.
And when the standard finally arrives,
you want to be
one adapter away from it.
Everybody else will be
rewriting their product
to accept it.
– Serguey Asael Shinder
