
The Configuration Complexity Clock (2012) - omnibrain
http://mikehadlow.blogspot.com/2012/05/configuration-complexity-clock.html
======
Terr_
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!

~~~
chubot
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.

~~~
Terr_
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.

