As I tweeted, change may violate design of a program, but changes to implementation that violate our expectations are worse.
In software development, the design becomes useless if the user elects not to use the application. You might have the most amazing and thorough design, but if it doesn’t attract and entice users to use the thing, what’s the point?
In configuration management, process can help cover all the documentation needs, but if it’s so much that a developer strays from the process entirely, what’s the point?
But these are often just academic exercises…
Suppose a meteor landed on your house. Assurance from your neighbor that everything will be alright — while correct in emotional terms — isn’t as good as their offer to pitch in and help clear the wreckage and salvage whatever precious goods may have survived.
But that’s just a hypothetical…
In employee relations, consistency is key when working with employees. People in general, really. If you tell someone that they matter, actions that suggest that they don’t will breed skepticism and distrust. An employee may be fine in the knowledge that they’re an entry in a profit/loss ledger so long as their financial needs are being met, but once expectations are raised and the employee feels valued, actions that make them feel undervalued are a violation of expectation.
In a labor-based economy, employee knowledge and expertise are considered precious goods, but more important is what the employee is going to be capable of in the future. When policies that affect employees change in ways that could be construed as inequitable, pleasantries won’t be enough of a consolation to mend that tear in trust.
That isn’t to say that design isn’t important, but design for the sake of design is foolish.