The mysteries of flexible software

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?

Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world

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