“Better safe”? You’ll be sorry…

Please – don’t tell me you’ve never done this.  You’re packaging up some software and you have a nagging concern about something.  What happens if this gets installed in Glassfish instead of JBoss?  This may not work, hmm, if case-sensitive passwords are enabled on Oracle11g.  So you put in some scaffolding to handle the untested case.  ”Better safe than sorry”…

You retest on JBoss and Oracle10g and it does something a little funny.  But you’re fairly confident, so you hack away a bit more ’til it feels like it’s back to normal.  Suddenly you have to ship and who knew your deployment process was 40% longer and the package 20% bulkier?

When I describe it like this, it’s easy to see how wrong this is.  But let’s recognize what drove us to this point:

• possible dependencies uncovered and acknowledged late in delivery cycle
• incomplete testing of reasonable customer deployments
• not really being sure of your code to handle these contingencies.

We end up with a kludge tower.  Again. Most of the time we make kludge towers to avoid resolving – and simplifying – software dependencies.  We put on some extra spackle or baling wire just to make sure.

It doesn’t really make it any more sure, does it?

And when you get to revising it and maintaining it and extending it, all those extras to handle those special cases make your software crumble on you.  Makes you feel safer, doesn’t it?

So if you’re not sure:

• if it’s needed
• whether it actually fixed the special cases intended
• whether it really is “orthogonal” to other parts of the software
• the details of how it works
• why it’s as “safe” as you feel it is

hmmm….  why would you want to include such a kludge?