I'm going to buck the trend here and say that there might be reasons to
continue working on the job you are doing for a while longer, and it migh be
better not to rewrite the old application even if the code stinks to high
heaven.
As a consultant, I've had to do that kind of work quite a bit, and I find that
there are techniques for making the process work. You may in fact, be right
that the program should be replaced rather than repaired, but management has
made its decisions for what may be sound business reasons, and-someone- will
end up tasked with fixing it.
When working on code like what you're describing, the key is to figure out
ways of isolating bits of functionality so you can be confident of changing
them without side effects, make that change - then make the fix. Each time
you do this, you risk breaking the code, of course, just as you do each time
you simply may a fix, but then the code is that much easier to maintain when
yo start the next fix, and doing the code restructuring first doesn't actually
make each fix harder.
A key point here is that you are not ever trying to simultaneously fix code
and restructure code. First restructure only, and test that the code's
behavior does not change as you go (also known as refactoring). Only after
the restructuring is complete, and you're confident you've decoupled the code
aspect you need to work on, do you implement the actual fix.
Another key point is that each code restructuring is the smallest one that can
help with the next task you have to do, and the restructuring iteslf is broken
down into tiny steps, each of which should not change the code's current
behavior, and do at least minimal testing after each small change. It's fine
if, to make the changes in small steps, you have to write some temporary code
that will be replaced in the next step or 2, and it's fine if such temporary
code contains a little ugliness such as duplication in order to get you
through the step.
The neat thing about this approach is that each little step can make the code
enough clearer to make the next step more obvious to see and easier to
implement. For instance, if you see a mile-long procedure with nearly
duplicated code repeated 16 times, don't try to do a full analysis of what's
truly the same between all of them, but find one chunk within each block
that's clearly easy to factor out. If that block was, say 3 lines ling, the
original procedure is now 32 lines shorter, and what's left has less
duplication. The next step is now easier. Soon enough, that original
function is now called by another and is overkill, so you can absorb it back
into the calling function, etc.
On Thu, 24 Mar 2005 18:11:26 -0600, strvariant <no.email.com> wrote:
Our company contracted with an outside consultant over a year ago to
build a complex database application. The end product was put into
production over nine months ago.
Since then it has been nothing short of a disaster. There are multiple
instances of problematic code that while they work well enough to get
most of the job done they continue to fall short of performing like a
database should. Since the application went into production I have been
the lucky soul who has been tasked with supporting it.
I am an experienced VBA/Access programmer who is being asked to provide
band-aid fixes to a system that is in dire need of a major overhaul.
These patches work on the part they are designed for but there are
dependent systems that fail when the new design is implemented. Once the
dependent systems are patched the original band-aid needs to be rewritten
to account for the other fixes. Then other systems fail and the process
starts all over.
My requests to fix the problems once and for all by providing a
replacement system have repeatedly been shot down by middle management
for various reasons. I have provided documented proof that the system
does not work to all of my superiors. But I am still not given the
opportunity to replace it. I am asking for advice on how to deal with my
problem 'clients'.
Thanks
strvariant