Software is interesting.

At the end of the day, running software is nothing more than large sets
of numbers undergoing manipulations through complex mathematical
functions (known as algorithms) which are themselves, nothing but
numbers.

Numbers are interesting.

Sometimes, numbers are used in software to represent themselves i.e.
financial calculations where you feed numbers in and get numbers out.
Sometimes, the numbers are used to represent other things - symbols.

Symbols are interesting.

The symbol 'A' for example is, as far as most computers are concerned,
the number 65. Fed into the appropriate function, the number 65 appears
to be manipulated as a letter from the Latin alphabet, not as a mere
number. The software we create floats on a vast sea of symbols and
functions that manipulate these symbols. Indeed, every bit of software
we write, adds to the vast sea of symbols and functions.

Functions are interesting.

Remember your high school math? Do you remember all those functions
(sometimes dressed up as equations)? Given some numbers, you plug them
into a function and out pops one or more other numbers. The numbers you
feed in are the 'parameters' of the equation. The parameters are the
bits that are left unspecified so that a function can becomes general
purpose.

Parameters are interesting.

Parameters are the key in turning a calculation into something that can
be reused in a variety of contexts. Without parameters, we cannot get
reuse from functions.

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.

Custom designed functions are interesting.

Every time we create a custom-designed function, we have to ask
ourselves 'what numbers in the core function should be left unspecified
- parameterized - in order to make the function general purpose and
reusable?'

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.

Isn't that interesting?

» posted by ITworld staff

ITworld

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine