---

I’m now maintaining and developing code that was out of my hands for a long time, and I found an interesting phenomenon I call “bad medicine”. The developer in charge of the code while I was gone knew something was wrong, but could not figure out how to fix it. So he added a crutch here and a splint there to keep the sick code “breathing” and quickly moved along.

Let me rant a bit about my experience with Programmer Joe and his bad medicine.

1. An Unhealthy Dosage: Code replication

Why, I wondered, would Programmer Joe copy a large code piece only to do some minor changes in it? Only half way through refactoring the code, I realized the answer: Old P. J. didn’t understand the code enough to be fix it inline, so he just copied it and tweaked it until it worked the way he wanted. Nice work, Joe. Customers  love increased footprint and a healthy dosage of repeated bugs.

2. The Splint: Data out of place

There were definitions inside the code file that were moved to the header file. That was weird, even for Joe. These weren’t functions made public, you see, these were data, large arrays of data, defined as “static const” and moved to the header file. Again, I figured the footprint-conscience customers must love Joe, but why, why, why?! I moved the data arrays back to the code where they belong, and recompiled to reveal the errors – in our sample code. Now, if your own sample code needs you to move data to the header file, you know something is wrong, but you should also know that what you are missing is an access function. Actually, there was an access function, only Joe didn’t know it.

3. The Crutch: Constants from heaven

Knowing what arguments to pass to some function can be tricky. How lucky was Joe, then, to find such a handy definition:

#define ARBITRARY_NUMBER (5)

Ah, wait – it was the other way around, wasn’t it? This time Joe felt responsible enough to make it obvious, other times constants just appear out of thin air. Joe couldn’t be bothered to find the real value to pass, so he found a value that works – most of the time, at least. Now, every time I see some obscure definition out of place an alarm goes off in the back of my head.

BTW, Joe – 42 is the REAL answer to the universe problems.

4. Placebo: Errors firing the wrong way

Repeatedly in programmer Joe’s code, error codes were returned for various reasons: Data was not there? Return an error. Wrong state? Return an error. Don’t know what to do? Unexpected input? Feeling sad? Return an error. Not always wrong, of course, but actually attempting to handle the problem might work better.

What’s worse, is P.J. returning an error to a caller that’s not interested: a timer pops, the function encounters an error, so Joe decides to return an error. The timer engine doesn’t care, of course, so the error is never handled. An attempt to do something, even if it’s notifying the layer above or even log the error, would have worked much better.

5. Prayer and Positive Thinking: Holy code

Joe finished his sacred work and felt much better; the sanctity of the code was not harmed. He only had to duplicate some data, and reverse half of what the “holy code” did, but the code itself was not touched. Joe said another little prayer for the health of whoever wrote the code years back and went on with his life.

Holy code is the hardest to catch, but it’s really worth the while. You have to look back through the versions and see what code was left untouched – no code is that good. It is more likely that that piece of code was sanctified, and any bug in it was undone before or after it.

So are YOU Programmer Joe too?

If you’re given someone else’s code, and you need to maintain it, please: MAKE SURE YOU KNOW WHAT YOU’RE DOING BEFORE YOU START MUCKING AROUND!