This has a lot of overlap with the Inner Platform Effect. Eventually you have a new programming language softcoded without any of the quality or tools you'd expect from a "real" language.
In my current workplace, there's a lot of internal business-logic which has been shoved sideways into INI files or database tables... Even SQL fragments used to generate other queries.
I think one of the major causes is that, somehow, the organization came to count off-cycle releases as a failure or black-mark, regardless of why they occur. So instead of improving the integration/release process (and using solid and tested tools for expressing and testing business logic) everyone instead tries to cover their own ass, inventing buggy layers of indirection so that they can avoid being the scapegoat who asked for a new push.
IMO a very useful question is "Who will change this, and how quickly must the change go through?"
For example, If it's an environment settings (e.g. database credentials) then it needs to be softcoded in a way that IT can edit and keep their own backups. But if it is business-logic that needs to be run validating against unit tests anyway, then by all means put it in "real" code!
It's even worse if the thing you develop and sell is a platform. What started as a strength (you can customize, configure, adapt the program to your needs) turned into something complex and convoluted that overburdens the customers and actually hinders sales and adoption.
And it goes on, that even related tools don't get build as "Tools" but as Toolboxes/Frameworks to build your own Tools.
Hm it sounds like this problem is caused by having high barriers between developers and operations.
A configuration push and a code push aren't really different in principle, but a lot of organizations make them different in practice. You should be able to recompile your binary reliably and reproducibly!
Where I work, developers and operations work out of the same source tree. I can see a lot of advantages in this style and few disadvantages.
That's what makes it strange: At least for our group, it's not even a binary, it's PHP. Unless a database-schema changes, things ought to be simpler than they are.
In my current workplace, there's a lot of internal business-logic which has been shoved sideways into INI files or database tables... Even SQL fragments used to generate other queries.
I think one of the major causes is that, somehow, the organization came to count off-cycle releases as a failure or black-mark, regardless of why they occur. So instead of improving the integration/release process (and using solid and tested tools for expressing and testing business logic) everyone instead tries to cover their own ass, inventing buggy layers of indirection so that they can avoid being the scapegoat who asked for a new push.
IMO a very useful question is "Who will change this, and how quickly must the change go through?"
For example, If it's an environment settings (e.g. database credentials) then it needs to be softcoded in a way that IT can edit and keep their own backups. But if it is business-logic that needs to be run validating against unit tests anyway, then by all means put it in "real" code!