I've seen the opposite, where the effort and bureaucracy to change the software is so prohibitive that changes are made to electronics or even mechanics to avoid a software change.
"It's OK, it doesn't need any code changes, just a modification to the configuration files, so the approval process does not apply."
That company's developers just need to learn the trick of making the configuration file format Turing-complete.
If you don't have time to write your own interpreter, XSLT is an easy one to sneak by PHBs.
I've seen one system where 70-80% of the functionality was implemented in XSLT for this reason. It meant changes could be delivered in 5 days instead of 35. Obviously good news for the customer. The PHBs were pleased that the bug count in the C++ core had dropped (it hadn't really, we just stopped using the buggy modules.) The integration testers were pleased that the end product worked. Basically everyone was happy except the C++ reviewers in QA.
he's talking about in the middle of a project. Not some giant legacy software system written in cobol running on a 30 year old mainframe where all original developers are dead and no original source code or documentation exists.
