The article mentions how one part of change is that regulations may have changed. I work in a heavily regulated industry, and am dealing with a set of regulato

The article mentions how one part of change is that regulations may have changed. I work in a heavily regulated industry, and am dealing with a set of regulators nearly all who depend on just one particular auditing company to ... effectively write their regulations for them. To the point where a new jurisdiction happily refers to their draft regulations as documents prefixed with the auditing firm's name on them. (This is not a joke or hyperbole.) That particular company has trained their own workforce to evaluate acceptance criteria according to their internal workflows and practices. This in turn means that almost all industry regulations are geared not towards functionality, but to make sure the auditing company has the least amount of training to do. As far as I am concerned, this is a particularly perverse form of regulatory capture: it's not even the industry at large writing their regulations, but an already entrenched gatekeeper acting on their own interest, crippling both the regulators and the companies in the industry. Now, I have no problem with regulations as such, because for most parts the rules tend to make good sense. But I do have a problem with regulations shaped after the desires of this particular auditing company. Instead of focusing on results, quality, transparency, accuracy, recoverability and functionality, they have a fixated view on particularly dubious change management processes. I am convinced that at some point in history, someone has done extensive research into 70 years of software engineering best practices - and gone to extreme lengths to expressly reject as many of them as possible. Two examples: they insist that even unit tests MUST NOT be written by the engineers who work on the code; and they are mortally afraid of the idea that engineers who work on a problem could ever understand and evaluate the problem. (Not to mention that the very concept of a workflow tool is completely alien to them.) The end result is that you can either try to do software well, or you can try to do it according to regulations.