Why Configurability Always Goes Too Far
By: Eugene Marin
Tags: Configuration Management, Software Development, Programming

Constantphobia

Constantphobia — a condition widespread among software developers, constituting an uncontrollable fear of hard coded values (constants). — Nonexistent dictionary.

Consider the following example: You’re working on an optimization of a background migration process, that takes a bit too long. The process involves compressing a list of data files into an archive, and sending it elsewhere. Now, you’ve come to realize that the compressing is what takes most of the time, so you decide to parallelize it: Let it write 8 archives in round robin, then unify them. Testing proves a great improvement. But now you’re wondering, of course, why 8? Won’t we want to change it some time later, or in some environments? Maybe it should be, like, configurable? This is also something your reviewer might ask…

Now wait. The question you need to ask yourself at that moment, that a lot of engineers won’t, is this: Who is going to change that value, in what scenario, to what value(s), and why? Well, 4 questions. If you can’t answer them and determine it’s worth it, generally speaking, keep it constant. Now, if you agree, you can skip to “Here, you do it.”

Here’s where it gets a bit controversial: A lot of engineers will say that even if you can’t answer these questions right now, you should put this value in the configuration, just in case. “You can’t regret this, but you might regret the opposite,” they’ll add, meaning you’ll have to recompile to fix this, should you be required to. In fact, no one knows if you’ll regret that configuration key. It takes lots of experience, accounting for specific factors and some intuition. But, you might indeed regret it very much. Allow me to demonstrate:

“Who is going to change that value?” In this case and many others, the answer is most likely “me, maybe.” What it really means: Nobody. See all these configuration values nobody understands and never ever touches? They have very similar stories: Unnecessary, undocumented (or not well enough documented), abstract values added by people who are no longer around, complicating the code and configuration files and slowing down upgrades and initialization. “In what scenario?” Assuming you do want to change it, it’s probably because it doesn’t work, meaning your tests were not great (and you don’t have any automation on that). It’s often an issue of lack of confidence in the code, which could be achieved with a good enough automation. Now fine, we don’t have that now, but then, “To what value, and why?” In this case there seem to be two logical options:

a. Change it to 1 to disable the parallel compression. In other words, we treat it as a feature toggle. Great idea, except we could’ve done this toggle in the first place. Are we going to define that we only mean to use either the default value, or the magic value 1 like some Easter egg? Why?

b. Increase the value, because it’s not fast enough. But are we going to do that? With a background process most people don’t even know exists? And how fast is fast enough? And, more importantly, is it going to work, and work well? Can it fail or hang if for example we put 10000 in there? Oh, right, we should have a minimum and maximum. Let me guess, they’ll both be constant? Congrats, now we’re adding both constants and the complexity of configuration!

But wait, there’s more! What about upgrades? Do we override it if it was changed by us and by the customer? What about backward compatibility if we move/remove it? Does it stay there as garbage (as many configuration keys do) or do we “migrate” it? And so on.

Sometimes “good enough” is the best. Constants are simple and internal, so if possible, save yourself and others the headache of excessive configurability. If for any reason you’re not confident enough with your new functionality, consider a feature toggle. But spare others from decisions they’re not necessarily capable of making.