The Configuration Complexity Clock (2012)
mikehadlow.blogspot.com
mikehadlow.blogspot.com
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!
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.