Generic |
Monday, 3rd May 2004 |
Programmers hate programming.
That sounds like a contradiction, yet it is true.
- Programmers love short programming code.
They are filled with joy when they can leave out a pair of {}.
- Programmers prefer to keep names of variables, methods, tables and columns limited to one character.
This efficiency
saves seconds, yet cost hours of effort during maintenance.
That does not matter, as programmers love to puzzle.
An hour of puzzling is far better than a few seconds of typing.
Congratulations.
The puzzle-type contradiction magnifies in software development projects.
A programmer that retypes the same statement twice immediately goes off puzzling for an hour.
Image you'd waste a few seconds on typing a similar statement on the third occasion!
It would be unheard of.
All too often the solution is something generic.
- That is fine when it takes the form of a reusable
method,
or a pretty super class with large chances for
inheritance.
- But...
every programmers dream is
to stop programming for ever.
- And yes, here comes the generic solution!
The generic solution
The generic solution is usually a bunch of parameters in a file or database table.
It can be quite complex to build a generic solution.
Programmers embrace this type of lovely puzzles.
To the project leader they sell it using the argument:
In future this will save us a lot of time
.
Nobody takes the effort to compute the actual number of saved seconds, as it would just spoil the fun.
There is big enthusiasm, the generic solution is on its way.
Shift
Oops, somebody has to fill the file or table.
Unfortunately this appears to be a boring type job, that costs seconds.
The solution is simple: Let's shift this typing to a system controller.
The system controller is in for an unpleasant surprise.
Odds are high that the solution seems only suitable for programmers.
So, in comes a short training and somebody has to write a user manual.
Shuzbuz, some more boring type work.
In production
At last, after a lot of effort the generic solution starts to work.
It is a struggle, as the test effort is more than doubled:
- Is there a bug in the parameters?
- Or is the generic software to blame?
Finally the whole bunch goes on to the production system.
Nobody does the aftermath on the real costs of the generic solution.
The original number of seconds typing are left unmentioned.
Up and running
The real world appears more tricky than anticipated.
All kinds of exceptions arise that make the generic solution less and less generic.
The set of parameters start to look more and more like a new programming language.
The original programmers have moved one, replaced by new ones.
To the new ones find the generic solution troublesome,
a YAPL (Yet Another Programming Language):
- One thing more to understand.
- One thing more to change.
- One thing more to test.
- One thing more to deploy.
- So, one thing more to worry about.
The cycle
Three years later the whole development environment and programming language are outdated.
The future was shorter than expected.
The whole lot ends up in the dustbin, replaced by something new.
The expected savings were never achieved and never will be.
Nobody knows about the original reason: saving time.
And maybe that is not too bad...
The programmers work with their new environment.
And... they notice they are retyping the same thing over and over again.
Mm, how about a generic solution?
Advice
Does a programmer propose a generic solution?
- Ask for the number of seconds saved in the coming 3 years.
Is it less than sixhundredthousand?
Don't do it, just continue typing!
- Ask how many days this generic solution will cost in documenting, discussion with other departments, education of new programmers and coping with future exceptions.
Convert it into seconds and compare it with the savings on typing?
Are the costs higher than the benefits?
Don't do it, just continue typing!
Till next, hand typed nut,
Nut