Of course a lot of the software job is maintaining things. We don’t get to work on new code that often so we have to deal with code other people have written, or code that we’ve written a long time ago.
And how to best describe this activity? Well if you’re lucky, or if you’re clever and tidy, you’ll have made sure that the code is neat and well formatted, the functions or methods are not too long and heavily indented and you may even have defined unit tests (if you believe in that kind of thing) to help you modify the code without breaking things too much.
More often than not though the code you’ve inherited or having to debug is difficult to understand, badly formatted, and comes as if written by a cabal of rabid monkeys after a raid on a sugar factory. Indeed for the last few days I’ve had the pleasure of trying to track down a bug in some VB code which appears to be something to do with either file handles or database connection record sets going out of scope.
This isn’t made easier by the fact that we’ve recently moved to Oracle 11g. So this could even be down to some vagary of the ODBC driver memory management changing – or it could be something to do with a Microsoft security patch even. However before testing out any of these options (as that would require re-installing Oracle clients) I’ve been trying to track it down with good old debug statements.
However, I’m still stuck several days later. It appears that a CreateObject(“ADODB.Connection”) call will create a recordset ok – however the scope of the recordset seems to wave around seemingly at random. Well, perhaps tomorrow I’ll try another tack.