The Configuration Complexity Clock (2012)

There is a tension between delivery speed and operational safety. The faster you deploy new service code, the faster you can take down your service because of a bug that slipped past your automated tests. This is why one-box deployments and traffic shifting and feature flags exist (which are increasingly config-driven).

And if you have multiple instances of your service running (e.g. regional endpoints), and you care about availability, then you'll be deploying sequentially to each endpoint and watching for anomalies before moving to the next endpoint.

There is still immense value in dynamic config in these scenarios.

I once worked at a place that reached DSL on the clock; no one understood the undocumented DSL (not even the programmers supporting it) but a few power users. I advocated re-writing rules in Python, using modern CI/CD techniques to allay fears of hard-coding. But it was too big of a philosophy change. The counter argument was "We don't want end users writing code!" but of course they were already writing code, just in a non-Google-able language...

That comment describes a real issue that the main post overlooks. But the comment also overlooks the obvious solution. It says:

>While "temporal" variations can easily be hardcoded if you have a short release cycle, "spatial" variations are not so easily hardcoded: you end up maintaining a source branch for each active variant.

But that's not the only way. There's a way that we are all very familiar with for customizing a component for being used in different situations: Passing in different arguments to the constructor.

If you have two places you want to deploy a piece of software, which have different environments and need to, e.g., access resources at different paths, then just have two main() functions, each invoked by one of two different executables. Those different main() functions can then hardcode all the specific details of whatever place you're deploying to, in your normal programming language, without you having to create configuration files or anything.

The driver here is needing to make changes to the behavior of the app in specified ways, faster than the release cycle. My advice is to go no further than key-value configuration settings, and keep a documented set of Postman requests in the repo to serve as your UI for developers to invoke.

This way you get the immediacy of being able to change prod behavior outside of the release cycle, the safety of knowing only your devs can make those changes, and the ability to easily build a real UI later if the hidden features become features you want visible to non-technical users or your customers.

A rules engine is where the descent into madness begins. Every single thing the rules engine tweaks needs to be an actual feature with actual RESTful routes dedicated. Overloading a configuration regime, which is only supposed to handle keys and values, into the key instrumentation for the entire application, bolts inevitably poorly-documented semantics onto the application.

Different devs or departments will see the two competing regimes and pick whichever one they like the most to add on to. You'll end up with two kingdoms at war. You want peace reigning throughout your empire.

Configuration is part of your application infrastructure. Rules engines generate competing semantics. Semantics are how the brain understands systems. You want one overarching paradigm, one source of truth for how things get done in your application.

The best thing you can do here is that if you use "8080" in a bunch of places in your code, replace all the ones that mean the same thing with a constant (eg, what port I'm running on), and the ones that mean something else (eg, what port the auth token engine is running on) with a different constant. Better still, use the URL library from your ecosystem to do this, and pester your 3rd party library authors to stop parting out URLs. If I had a dollar for every URL interpolation bug I've had to fix...

That way when you have a customer whose antivirus is running on 8080, you can finally pull it out into config files, and you 'just' have to change the people who consume the constant to pull from config. Because you've already telegraphed the intent to do this.

A few jobs back I saw another side benefit to this: you can entice people to participate in improving the code. When code is really wrong people will ignore it. They can't be bothered to get invested in it. But when it's almost right they are often motivated to fix it the rest of the way. Either they see the potential and are inspired (new blood, trying to make their mark), or the unfulfilled potential grates on their sensibilities (crotchety veterans).