Jon Udell points to a column by Sean McGrath:
Reuse is interesting.
We always strive for reuse in the software we create. Some of the functions we use are timeless and occur over and over again. Interest rate calculations, the number of working days between two arbitrary dates, that sort of thing. We put these general purpose functions into so called ‘libraries’. We try to reuse these libraries of functions over and over again through the parameters they give us access to. However, in most non-trivial software projects, there are many more custom-designed functions than there are reusable functions.
Parameterization is interesting.
Take interest rate calculations as an example. It does not take a financial guru to realize that the key numbers that need to be parameterized are the rate, the principle and the term. Unfortunately, as functions get more complex and more domain-specific, it becomes harder and harder to identify what numbers should be parameterized. For example, in a financial application, which aspects of invoice generation need to be parameterized and which do not? In a manufacturing application, which numbers need to be fed into the parts-reordering function and which do not? If we get the parameterization wrong, we will pay for it in costly code changes down the line.
Code changes are interesting.
A software application is nothing more than a mega-squadron of numbers, flying through lots and lots of functions (also made of numbers) in close formation. A gigantic, high speed display of numerical acrobatics. Smell the kerosene.
Given that it is all just numbers, the split between numbers that are easy to change and those that are not, is something that is under our control. Indeed, the very idea that there are numbers which can easily be changed and numbers which cannot be easily changed, is an engineering invention. It is *us* – not the machine – that creates that distinction. We write programs in things called ‘computer languages’ and we distill out the numbers we need with things called ‘compilers’. The rest of the numbers, we put into containers with names like ‘databases’ and ‘XML’ and ‘configuration files’ and ‘registries’ and so on.
The latter type of number is one we can change relatively easily. The former we cannot, due to rules of the game that we, not the machine, impose.
Given that the phrase ‘code change’ is almost synonymous with ‘cost’ we need to think very carefully about parameterization during software design. We need to get our programmers engaged with the idea.
Programmers are interesting.
In order to stay sane, most programmers concentrate on the part of the problem they are working on today. As a consequence, their view of what pieces of the functions under development need to be parameterized and which do not, tends to be a quite low level. Indeed, most of the items programmers will chose to parameterize will amount to double dutch to the business analysts.
Ask a Web services programmer to parameterize an application and the result might be that you can swap XML parsers without significant code changes or use a different transport protocol without code changes. Ask a business analysts to parameterize an application and they will most likely wish to be able to change business logic without significant code changes or add fields to databases without significant code changes. The two views of parameterization are equally valid but poles apart.
