The Left Field

Premature parameterization is the square root of all evil

Almost all software - regardless of its function in life - involves using computer code to operate on data. Sometimes (rarely) there is no data at all. Sometimes (not so rarely these days) the data is, itself, code.

In general, the relationship between the code and the data features a split on the data side. Some of the data is end-user, application data and some of it is configuration data. The configuration data is very interesting because the functionality of any application software is a function of how the code and the configuration data inter-relate.

In the trade, we often call it parameterization. We spend time finding the parts of the application that do not need to be "wired" into inviolate computer code and instead, we read those parameters from data files. The term "soft coding" is often used to describe this idea.

When I say that "we spend time" on parameterization I'm afraid that I often see that time spent sub-optimally - to the detriment of software development projects. To illustrate, lets take a simple example from mathematics. Mathematics is a great place to look when looking for examples of generalization done right. Mathematics is essentially all about patterns: finding them, notating them, exploiting them and, most powerfully of all, generalizing them.

Let us take the example of finding the square root of a number. How does a mathematician think about such a problem? Without a moment's thought the mathematician thinks about the more general problem of the N'th root. If you can figure that out, a solution for N = 2 just drops out of the more general solution. If you are in luck, to quote Polya, you may even find that the more general problem is easier to solve.

Now the parameterization here, from a software perspective, looks obvious. Instead of wiring 2 into your code you work with N and then your parameterization provides 2 or 7 or whatever as required. However, it is remarkable to me how many times the obvious parameterization turns out to be sub-optimal. To continue the square root example. Maybe your applications is manipulating equations? Well. mathematicians - the kings and queens of generalization - long ago figured out that square roots are just a special case of a more general concept of a Polynomial equation. If you can solve Polynomial equations, then all your square roots and cube roots just drop right out as mere special cases.

I often find myself cautioning developer to resist the very strong urges that come early in a project, to nail the parameterization and start slurping up configuration files. Like code optimization, it is often the case that waiting is the best strategy. With optimization, its important not to do it too early because your ideas about where the hotspots are, tend to be off base - often wildly so. You need to gather performance metrics to be sure and of course, to do that you need a reasonably complete application. Mantra: make it work, then worry about making it work fast.

Similarly with parameterization. Until the application is more fleshed out it is difficult to predict what the most potent form of parameterization will be. Mantra: make it work with wired in data. Then, worry about how best to parameterize it. More often than not you will find that your first instincts about parameterization have evolved considerably.