Click here to Skip to main content
Click here to Skip to main content

Tagged as

Go to top

The woes of a maintenance developer

, 30 Apr 2013
Rate this:
Please Sign up or sign in to vote.
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:

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 friggin' 2 days

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.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Jyothikarthik_N
Technical Lead
United States United States
Engineer.
Follow on   Twitter

Comments and Discussions

 
QuestionNicely put Pinmemberjkj20002-Apr-12 18:13 
QuestionBig Ball of Mud Design Pattern PinmemberSBJ7-Feb-12 8:08 
Questionhaha PinmemberBrad Benham2-Feb-12 9:42 
GeneralCheck this Pinmemberkosmoh2-Feb-12 5:10 
GeneralRe: Check this PinmemberJyothikarthik_N2-Feb-12 5:40 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web03 | 2.8.140921.1 | Last Updated 30 Apr 2013
Article Copyright 2012 by Jyothikarthik_N
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid