When running a software project, your task is to obsess over simplicity
The best software is simple. The most stable lines of code are those you didn’t ship with the end product. Yet most people in charge of these development projects deliberately choose to bloat their scope. For each feature, their first question should be: does this add directly to the goal of the project? If not, cut it out.
It seems logical to make software “expandable” or “more generic”. This seems to be common sense but hides the fact that those are additional features that come with their own cost.
“The allowed file types should be configurable.”
“We should be able to adapt the number of worker threads.”
“Let’s make our authentication system pluggable.”
Managers, architects and business stakeholders often believe this is the best way to go. After all: hard-coding is a limitation, no?
To those actually building the thing, it’s a warning flag. Those that have to test and support it in production, run for the exits. Like most easy requests, it comes at a high price.
In my opinion, there are only 3 kinds of valid configuration properties.
You’re using a framework that allows you to set parameters through config files. Great. There is no need to overwrite and hard-code them, but these params should be considered part of the code. Automated integration tests should be written with these values in mind. Changes should require a release.
Environment-specific values like database connection strings and passwords belong in config files (or some kind of encrypted vault). This list should be pretty limited for most projects.
If you need a framework to allow features to be turned on and off at runtime, then that’s a valid scenario for properties. However: it’s a complex feature and I do hope you’ve tested this mechanic.
Everything else should be hard-coded.
Because here is the question that matters:
“Would you ever change that parameter in production without doing a regression test?”
If the answer is “No” (and it most likely is), the properties are a dangerous form of scope bloat. They open the door to configuration abuse and unforeseen errors.
The configuration fetish finds its origin in the Big Annual Release. In the dark ages of software development, releases were so costly and full of risk that companies opted for only a limited amount. It wasn’t unusual to go live only once or twice a year. In that scenario, flexible configurations make sense. They give product owners a chance to tweak and adapt their software based on new insights without having to wait for the next quarter. People with a BAN mindset love configuration flexibility.
In modern software development, regular releases are the norm. As often as possible. An insight in the morning could be processed, implemented and released to production in the afternoon. The regular releases give you freedom and flexibility that config parameters just can’t. Automated test frameworks and the chance to pass through manual testing secure quality. Given the low cost, low risk of releases, modern software developers have no reason to opt for configuration changes.
When running a software project, your task is to obsess over simplicity. Adding configurability as a feature just because you can, is an anti-pattern.