Compatible Doesn't Mean Identical

When you swap one component for a "compatible" one, ask who is going to judge the result, because the person who made the swap is rarely the right judge. I watched this play out recently on a small piece of interface work: a licensed font had to go, for entirely sound legal reasons, and it was replaced with an open alternative built specifically to be metrically compatible with the original. Same character widths, same spacing, same general shape. On paper, a clean substitution. On screen, a short line of tagline text sat noticeably heavier than before, and the person who'd have caught that immediately wasn't the one reviewing the fix.

Nobody did anything wrong. The engineer who made the change solved the problem they were asked to solve. The font's licensing risk was real, the replacement was chosen precisely because it was designed to be a drop-in, and by every measure that mattered to the original constraint, the fix was correct. The trouble is that "solves the licensing problem" and "looks right" are two completely different tests, decided by two different kinds of judgment, and only one of them had actually been applied before the change was ready to ship.

This is a pattern I keep running into well beyond fonts. It shows up whenever a technical substitution is justified against the criteria that made the substitution necessary, rather than against the criteria that made the original choice good in the first place. A library gets swapped out for licensing or maintenance reasons, and the replacement is judged on API compatibility, when the thing that actually mattered was subtle timing behaviour nobody wrote a test for. A cloud service gets replaced to cut cost, and the replacement is judged on throughput numbers, when the property customers actually relied on was consistent tail latency under load. A vendor gets switched for commercial reasons, and the new one is judged on contract terms, when the thing that made the old one workable was a support team that picked up the phone. Compatibility is always compatibility with respect to something specific, and it's easy to mistake "compatible with the reason we're switching" for "compatible with everything that mattered about the original."

The reason this keeps catching people out is that the constraint driving the change is usually the loudest thing in the room. A legal risk, a rising bill, a contract that's expiring — these create urgency and a clear, checkable success criterion. "Does the new font satisfy the license" is answerable in an afternoon. "Does the tagline still carry the same weight it used to" is a judgment call that requires someone to actually look, and looking doesn't feel like part of solving the urgent problem. So the checklist gets satisfied, the ticket gets closed, and the softer property quietly changes underneath everyone, because nobody was ever explicitly asked to check it.

The fix isn't more process. It's being specific, at the moment you decide to substitute something, about which properties you're substituting for and which ones you're simply hoping survive the trip. If you can name what actually made the original choice good — brand feel, latency under real load, the quality of human support when something breaks — you can also name who is best placed to notice if that property has quietly gone missing, and route the change past them before it ships rather than after someone complains. That person is often not technical at all. The designer who chose the original typeface, the account manager who knows what the client actually complains about, the on-call engineer who remembers which failure mode used to be silent and now isn't — these are the people who carry the tacit knowledge of what "good" meant, and they're frequently a step removed from whoever is empowered to approve the change.

There's a commercial version of this worth being honest about too. Sometimes the answer, once you've actually looked, is that the difference is fine — a slightly heavier tagline costs you nothing a customer will ever mention, and holding up a release to debate font weight would be a worse decision than shipping it. That's a legitimate outcome. What makes it legitimate is that someone with the right eye actually looked and made that call, rather than the difference sailing through because the only test anyone ran was the one that measured license compliance. The point isn't that every substitution needs a design review or a performance audit before it can ship. It's that skipping that look is itself a decision, and it should be made on purpose by someone qualified to make it, not by default because the loud constraint had already been satisfied.

This matters more, not less, as more of this kind of substitution gets automated. It's straightforward to write a check that verifies a new font's metrics match the old one, or that a new library's public API surface hasn't changed, or that a new provider meets a latency SLA on paper. It is much harder to encode "does this still feel like the thing we built," and that gap doesn't close by writing more automated checks — it closes by making sure a specific human being, chosen because they'd actually notice, gets a look before the constraint that felt urgent gets to stand in for the constraint that actually mattered.