The woes of a maintenance developer

Call it a bad choice, fate or ill luck. Or all together – I’m struck and it has been almost a year since. I’ve learnt to live with it but the developer inside me keeps hurting. A huge code base of unmaintainable and stinking code (talk about code smells!) it’s like your nose itch when your hands are tied. What irritates the most? I’ve borne the brunt, bitten the bullet and patiently made a little list:

Foul stench: Martin Fowler talks about Code Smell. It is a surface indication that is related to a bigger problem in the system. If you’re working on a maintenance project and your luck is at odds, then chances are it’s more than just a smell – It’s a stench! From ill-written [or zero] comments, to insanely long method with ridiculous names - you name it and there it is.

Let me quote a couple of examples, any idea what the below method does?

public String ReturnString(String input)

Prepare for it: It accepts a string input, opens an XML file, and hops through each tag, returns value of the tag matching the input. This goes on for almost all the tags in the XML file, i.e., the method is called a pretty 200 times each for each of the tags in the XML file.

Didn’t expect that, eh? Me neither, until I assumed it to be a piece of junk string to string conversion method and tried to chuck it off! This is just not it.

As part of an optimization drive (I never learn from my mistakes), I fumbled upon the code below:

public void Method()     {
  if(condition1) {
    //1000 lines of code
  }
  if (condition2){
    //EXACTLY the same 1000 lines of code
  } 
  else{
    //Oh wait, it's the same 1000 lines of code!

  }
}

My heart cringed at the site of this and I refactored it into something very pretty and efficient.

What happened next? Check the next section.

The Karma called Bug: Turns out that the 1000 lines of code had one line and just that one line altered in each of the conditional blocks. And what’s worse, none of the tests covered and it was from the customer from whom the defect came. Believe me; it took a good couple of days of code digging to figure out the source of a weird error.

So that’s the curse of an ill developed maintenance project. You are not to indulge in any refactoring unless you are ready to take full responsibility for any weird defect that may crop up, few minutes from now or few years from now or something that may never.

Paralysis by Analysis: This is my favourite part. All through the years of graduate study, you learn all tricks of the trade: from object oriented analysis design till may be even Artificial Intelligence. You learn all your skills and finally wind up as a maintenance developer filling scores of word documents and excel documents. I still vividly remember all those Impact analysis documents I filled out, none of which truly gauged the actual impact my two lines of code were going to make. Here’s a rough estimate of the whole saga of the release:

Hilarious, isn’t it?

To sum up, here are a few points if you’re a maintenance developer – maintaining an ill-developed application:

1. Thou shall not optimise
2. Thou shall bear in mind that bug is inevitable
3. When thy smells stinking code, remember rule 1
4. Thou shall blame any defect on the developer or the previous maintainer whomsoever has left the organization
5. Thou shall not crib

And a final word of wisdom for all the developers out there: Always develop applications keeping in mind, that the maintenance developer is an crazy axe person who knows where you live.