> therefore, you will be externalizing these values and decouple them from the application, which will give you great flexibility in the long term<p>I think this is one of the worst "Best Practices" ideas that are parroted by people who haven't thought deeply about the issue. It's really a bad legacy from the era when most software was actually <i>distributed</i>. Now that most software runs in environments that are controlled by the same organization that developed the software, the principle is far less valuable.<p>Nowadays, most software should have most of its configuration information - paths, DB URLs, HTTP endpoints, etc - hard-coded into it. This strategy follows the "convention over configuration" philosophy, and it gives you a range of benefits. First of all, you can run tests on your config to make sure everything is working properly (check various files are present, do a SELECT * LIMIT 1 from DB tables, etc). You can catch config errors at compile time, eg by using enums like prod/dev/qa to represent environment names. And it prompts you to apply a refactoring mindset to your config - when you notice that your config code is repeating itself extensively, you'll realize this and be able to take steps to refactor, standardize, and simplify the config.