Working in a much less formal environment, I still religiously abide by a backward compatible concept whereby new code can require new conditions (e.g. schema c

Working in a much less formal environment, I still religiously abide by a backward compatible concept whereby new code can require new conditions (e.g. schema changes) but those new conditions must be invisible/transparent to old code. It’s generally very risky to put your state of world into a place where the old code can’t even look at it. Because rollouts and fallbacks become much harder to orchestrate. Mostly it provides the property where you only need to worry about writing environmental upgrades and never downgrades even if you sometimes fall back to older builds. However the story in TFA is a bit different. What we have is an incompatibility between two versions running side-by-side. Nothing wrong with Version A or Version B per say, but just that you cannot roll out B progressively. Obviously the only fix is to immediately get your environment homogenized in A or B, and maybe there is actually a valid decision / risk analysis to go one way or another. For example, if you don’t respect the backward compatibility edict outlined above, it could be tricky to downgrade your B instances back to A depending on what state changes in the data B may have already made. But the real problem is actually one level deeper. The fact that B got to the point of being rolled out with a catastrophic incompatibility with A means that DEV is fundamentally not testing for the ability to do a progressive rollout before they actually start doing one. The new B code was never actually tested in a heterogenous environment with A, meaning these rollouts must have been happening on blind faith alone.