How Configurable Should Code Be?

One interesting problem developers run into is the number of configurations a project should have. This isn’t a magical number, but rather the balance of configurations, conditions to handle and what the code is attempting to accomplish. This article I’ll go over some scenarios and general discussion about handling configurations.

About-config | Created by: Sthoby from Wikimedia (Creative Commons License)

So what is a configuration? A configuration is simply a programmable option that modifies how the program functions for a users use-case. Anytime you have changed a PC background, zoomed in on a page, or went into a game and changed the graphics. You have modified a configuration provided to you by the software. However, when changing that configuration on the other hand that configuration must be handled for the best user-experience. If not, this makes software unusable for users who expect/rely on those configurations to work properly.

On the other hand, we can use configurations for development of a service, process, or pipeline. We can distinguish how the code operates in certain environments, don’t run sections of code during testing or any reason that can be thought of.

Alright great, configurations are amazing as they allow the program to run differently, but at what cost? Well each configuration is a new use case that has to be supported. When you add a new use-case that’s potentially code that has to be added and maintained, new code to be tested, and new changes to be deployed out. Remember that each configuration has a cost, this cost of adding a new configuration for usability versus the cost of adding it. As long a reasonable agreement is made then it’s fine.

Gear Option Engine | Credit: Raphael Silva on Pixabay (Creative Commons License)

For example, let’s say you want to run a specific configuration for testing locally that wouldn’t perform any cloud operations. We could simply lump all of our cloud operations code into section of code, especially if we do 1–2 operations this keeps things simple. So the code would like below (Python):

def myFunc():
    doWork()   
    if config['shouldPublish']: # assume this is a simple boolean
       writeToS3()

This is a really dumbed down example however it illustrates a simple point. So now we have a way to write unit tests for myFunc , integration tests, and other use cases. However, is this configuration necessary? The code could be much simpler as a local S3 setup that allows you to emulate a cloud environment instead of ignoring writes to it for the sake of testing. It’s a mix of what you want to do plus what is achievable.

So keep in mind what you are doing with configurations throughout the code. While everything is configurable doesn’t mean it has to be and other ideas/processes should be thought of in order to prevent configuration overload.

Thanks for the read.