I honestly don't think this is true. The word invariant might not be part of their toolbox, but that doesn't mean they don't understand what a condition that ho

I honestly don't think this is true. The word invariant might not be part of their toolbox, but that doesn't mean they don't understand what a condition that holds true over some problem space implies. These things are built into existing infrastructure, they are bound to easily be rediscovered, noticed, understood. I think the bigger problem is that when people work in large groups for implementing a business logic, things are assumed invariant in one component of a system, not tested for in another component that relies on that condition, and what used to work ceases to work when that condition changes. If it literally isn't labeled "invariant" explicitly in some documentation, people learn to practice 'defensive programming', after enough frustration. Or they feel compelled to understand all the code in their code base, or migrate over to smaller companies, smaller projects where this is less of a headache (but not really, because we all depend on pieces of systems we can't always inspect in totality, therefore, can't always assume we know everything about the systems we are dependent on). The real world has edge cases. If the instructions are wrong, it's because either the invariant isn't actually an invariant in the real world, or the domain is modeled incorrectly. The higher up you get in writing programs about programs, the less likely it seems like real world data works this way, because you literally don't even have the common sense or perspective to see that some things change without being able to specify an underlying order to them (implying some things change without there being an order to describe their changing).