[JLangley]

REALLY worth reading the Graham Poulter comment in the original post about the difference between spatial and temporal variations.

The idea that you can hard-code everything assumes there is no variation in deployments and use of a piece of software.

If that were the case, you're talking about a SUPER simple piece of software. So sure, hard code everything.

But as soon as you're talking about a piece of software that will be used in multiple locations and with possibly different release / roll-out schedules, "there will be issues".

[catern]

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.