The points in this post reminds me of the “configuration clock”[1]. Hardcoded -> configure file -> rules -> DSL -> Hardcoded. Maybe it should be the “configuration ouroboros”. Provides one explanation for why this config becoming code situation occurs over and over and what to watch out for.
This came up in a recent podcast. They thought that the plain clock model doesn't account for real progress being made, and that a better model is the "configuration spiral": it looks like the clock when viewed from above but shifting your perspective a bit reveals that it's actually a spiral that describes how to build abstraction layers. Not that we hit the mark every time, but that a clock is too reductionist.
Precisely. In a case at work, I’ve found that some YAML is complicated because the abstraction level at which it’s describing things is too low; the fix is to move a most of the logic into code and keep some minimal flexibility in the YAML (or use SQL instead, though that choice is more about who we want to empower to edit it).
[1] http://mikehadlow.blogspot.com/2012/05/configuration-complex...