Configuration And Code Flexibility

The basic principle of code flexibility is to remove as many specifics as possible, that is, to make code usable in more possible scenarios. One of the key techniques of flexibility, abstraction, too tries to postpone the specificity as late as possible. Best practices like OO Design Principles guide you to loosely couple to the specification.

Code Is About Algorithm

Code is algorithm, sequence of execution, logic, anything else but data. The different levels of including data in the code can be seen as hardcoding, using variables, using constants, using enumerations, using custom types to using heirarchy to assign specific ownership of data. In each of these cases we are trying to postpone including data in the code execution. More we postpone mentioning specifics, the lesser we hardcode and the code becomes more and more flexible to be reusable.

The ultimate flexibility is when all the specifics can be pulled out of the code. The code can retrieve the specific data, which work as values, at run time and use them.

Configuration is the storage of specific data. It is something that should always accompany any code, right from a simple add function to an enterprise application. It makes life better for the user and the developer both.

Configuration For Customization

The more significant advantage of postponing the specifics to run time is that now the user can customize the software without a lot of effort. What if you could not change the font in your word processor? Would it be usable. Of course this is an example where this becomes part of the requirement. How about if you were not allowed to change the wallpaper of your desktop?

This customization can be taken to any end of the spectrum. The user can change the theme, the skin, the plugins, the other binaries to use, the output format or any aspect of the usage. What should the user be allowed to modify is a subjective thing and will also depend on the software.

A lot of times the argument made by the developer is that by providing too many configuration options the software can become too difficult to use. One of the better design paradigms applied are design is about reducing options. I completely agree with it, but with a grain of salt! I would rather prefer, design is about reducing options for the developer, not for the user. Design decisions are about selecting choices out of many so that the software can be developed. This does not mean that the software should be made less customizable. Also, if the user is comfortable with the configuration, it need not be exposed as customization. There are a lot of benefits of configuration to the developer him/herself.

Configuration For Reusable Code

A lot of times business requirements change, among which data change is more frequent. You should not have to change the algorithm because of data change. By pulling out the data you can now use the same algorithm binary with a variety of data, of course limited by constraints, and apply it to more scenarios.

One of the classic examples are Business Rules. If business rules can be separated from the underlying technical code, every change in the business rule will not result in a technical code change. This makes it more stable and more reusable. Even in the everyday software, separating out the business code from the technical code can help a lot. An example to consider is the details of connecting to a database. If it can be pulled out of your database code, you can work with multiple databases with the same code. And the place where it should reside is the configuration.

A lot of developers oppose to this idea because for some reason configuration is nowadays synonymous to storing using XML schemas. Configuration can be implemented anyway, in binary files, text files, XML files or the database itself. These decisions become important when you have to decide where would you store the database connection string, hopefully not in the database itself!

A typical example of using configuration effectively is in case of utilities, like loggers. If you are the author of a logger library and want your users to specify which logger (file logger, database logger, …) at run time, there is no option other than making it configurable. Your user can now choose to use a different logger without having to change the code. Even if you are asked to do this as part of a maintenance contract, the effort required is minimal.

Where To Check

There is no wonder that most of the software released is associated with a configuration file. The big disadvantage of configuration, or rather postponing the specific data to run time is performance. Depending on the project, the scale of data being retrieved and probably the environment performance can be hugely affected by it. The best thing to do in such cases is to optimize the code for performance before ruling out configuration.

The second disadvantage, but more manageable, is more effort required to develop the configuration code itself. It required a broader and deeper view into its possible use. Since configuration is one of the things that is used throughout the code, any interface change in future can cause a catastrophe for a project. Design of the configuration library is one of the most important things for any software.

This probably can sound too obvious to a lot of you. However, I have witnessed scenarios where it has been ignored or missed out because of pressures of completing the core requirements. Configuration is one of the things that are not necessarily part of methodologies or standard approaches. But it is a condiment that can make your software flexible and reusable.