I recently had a discussion with my newly appointed manager over his idea that having to redeploy the system in order to change its behaviour is bad and that configuration files would be a superior solution. As it happens our system is Spring contained so it does not lack configurability and we take advantage of that to support diverse environments. However that is not what he was thinking of. He was thinking of having the actual functions of the system being configurable. It took me a while to find a way to express why it is a bad idea and usually the result of a lack of design.

So let say you want to implement a function that in the context of the system sends an email to the system’s support team. Natural parameters of that function would be the subject and the body as these are known only during the course of the system’s operations. The subject, in this case is a configuration element. The configuration element here is the recipients email address. Depending on the circumstances you may hard-code it to, for instance, “support@digitalbrikes.com” and let the administrators of the e-mailing system figure out this address should map to actual people. You may make it a configuration parameter passed to the system at start-up time, for instance, “sales-support@digitalbrikes.com” or “web-support@digitalbrikes.com”. This can clearly be useful. Another solution would be to configure the actual list of people directly, for instance “denis@digitalbrikes.com, bob@digitalbrikes.com”.

So what the configuration does is it increases the number of parameters of a function. Say we call our function f(x,y), adding one configuration parameter means that now we have a function g(x,y,z). Overall this is not too harmful, especially in an object oriented context where the object would carry the configuration parameter. The development effort and testing effort remain similar.

Now let’s take a more complex example where two configuration parameters are used to determine the parameters of the executed function. So suppose that we have our g(x,y,z) function that sends an email to z. Let’s now suppose that our function is that we want to send emails with a given prefix to management in addition to support. We now have three configuration parameters: support recipient, management recipient and the prefix that will determine who the email goes to.

Now the situation is that we have a function h(x,y,t,u,v) to send our email. Clearly this is more complex to code and test. Lucky for us our particular function can be expressed as the composition k?g i.e. h(x,y,t,u,v) = g(x,y,k(t,u,v)), which is somewhat simpler to code and verify than a single five parameter function.

Throughout this post, it is obvious the configurability may be legitimate in the context of the system. What the examples illustrate is that it significantly and quickly increases the complexity of a system and that therefore it is expensive and should be used only when necessary. In other words reducing configurability should be a design goal (simplicity).

This entry was posted on Friday, March 13th, 2009 at 2:35 am and is filed under Design. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.