[jdwyah]

Yes. Env vars beat constants but have stunted our thinking because we know deep down it's not a great idea to have too too many.

Config files are better, but can lead to the mess described here and typically only give us crude axes for overriding.

It's time for us to embrace & tame the complexity. If you use a feature flag tool already, you know what it's like to target different values based on rules.

If I want to experiment with changing the http timeout for specific calls from a single service in a single region I should be able to roll that out.

It's time to expand our brains and bring this feature flag style thinking to the rest of our configuration.

[ilyt]

> If I want to experiment with changing the http timeout for specific calls from a single service in a single region I should be able to roll that out.

...why ? how often you do it ? What actual app feature it fills ? Why would you throw permanent code at something that you need to do once or twice?

That kind of thing is FAR better served as customizable hooks (loadable .so/.dll, maybe even attached Lua interpreter) rather than bazillion random flags for everything and checks cluttering code.

[jdwyah]

May need to agree to disagree :) I'm saying that we should write:

httpClient.get("my/url", timeout: config.get("http.timeout"))

Where config is a library smart enough to do some rule evaluation over a live updated backing store to get the right value.

I'm not sure how .so/dll or lua is going to help here.