The woes of a maintenance developer

Call it a bad choice, fate or ill luck. Or all together – I’m struck. 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 you’re hands are tied. What irritates me 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 kind of 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 no] comments, to insanely long method with ridiculous names it has everything. Let me quote a couple of examples, any idea what this method does?

publicString ReturnString(String input)

It accepts a string input, opens an xml file, and loops 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 tag 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{//again, the same 1000 LOC
}
}

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 just one line (actually one variable) 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 will never crop up.

Paralysis by Analysis: This is my favourite part. All through four years of graduate engineering 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 spreadsheets. 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:

Requirements elicitation and clarification

3 days

Design – Detailed level with Impact analysis

10 days

Test plan preparation

5 days

Coding and Testing

10 days

Net number of LOC added – 5, just freakin’ 5

Hilarious isn’t it?

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

Thou shall not optimise

Thou shall bear in mind that bug is inevitable

When thy smells stinking code, remember rule 1

Thou shall blame any defect on the developer or the previous maintainer whomsoever has left the organization