Why backwards compatibility is a sustainable investment mindset in action
Last December, twelve pages on an enterprise client’s corporate website broke simultaneously. Not because someone pushed bad code. Not because of a server failure. Because a pre-release version of a component went live before it was ready, and every page using that component inherited the unfinished changes.
Twelve pages. One component update. Zero warning.
The natural reaction to something like this is to figure out who made the mistake and make sure they don’t do it again. But that reaction treats a structural problem like a personnel problem. The real question isn’t “who let this happen?” — it’s “why did the system allow it to happen at all?”
This is where one of our guiding values at Johns & Taylor — Sustainable Investment Mindset — shapes how we think about component architecture. Every page on a large-scale platform represents an investment. Design time, development time, content strategy, QA cycles, stakeholder reviews. When you modify a shared component in a way that breaks existing pages, you’re not just introducing a bug. You’re devaluing every investment those pages represent.
Our rule is simple and non-negotiable: never overwrite an existing component version. If you need to change behavior, publish a new version alongside the original. V1 stays V1. The new version ships as V1.1. Both coexist. Pages using the original keep working exactly as they did. Pages that want the new behavior can opt in.
I know this sounds like it could create bloat — a graveyard of old component versions cluttering up the library. And yes, managing that lifecycle requires discipline. But the alternative is worse. When teams overwrite components in place, they create invisible dependencies. Every editor using that component becomes an unwitting QA tester. And the editors — the content strategists, the marketers, the communications teams — shouldn’t have to worry about whether publishing a page will trigger a visual regression they didn’t cause.
After the December incident, we didn’t create a new training module. We raised it as an architectural concern with the platform team. The system needed to make breaking changes structurally impossible, not merely discouraged. That distinction matters. Training addresses behavior. Architecture addresses capability. If the platform can’t accidentally ship a pre-release component, then no amount of human error can reproduce the problem.
This principle extends into how we think about enhancement requests, too. When someone on our team has an idea for improving an existing component — better animation, cleaner responsive behavior, additional configuration options — we don’t ask them to hold back. We want those ideas. But the improvement gets built as a new iteration, and the story points for migrating existing pages get estimated separately. The Agile process decides whether the migration is worth the investment right now, next sprint, or never.
That “or never” is important. Sometimes V1 is perfectly fine for the pages using it. Not everything needs to be on the latest version. The sustainable investment mindset means recognizing that migration has a cost, and that cost needs to be weighed against the value it creates — not assumed as overhead you just absorb.
I’ve seen organizations that treat backwards compatibility as a constraint — something that slows them down, something they’d abandon if they could. But the fastest teams I’ve worked with treat it as a feature. When your team knows that their work won’t get broken by someone else’s update, they move with more confidence. When your editors know that publishing a page won’t trigger unexpected visual changes, they publish more. When your stakeholders know that last quarter’s investment is protected, they approve the next investment more readily.
The sustainable investment mindset isn’t about being conservative. It’s about being honest with yourself about what you’ve already built and making sure your next move doesn’t undermine it. In component architecture, that means versioning. In broader business terms, it means recognizing that the things you’ve already shipped have ongoing value — and protecting that value is just as important as creating new value.
Don’t break what already works. Build alongside it.
