Leaving It Better Than You Found It

January 26, 2010

When my wife and I bought our house back in April, one of my pet projects has been to renovate the room over our garage.  I knew buying the house that it would be a lot of work, partly because the previous owner didn’t know what he was doing when finishing a room.  I’ve spent the last week and half sanding, mudding, and fixing all the walls in this room.  While sanding some dried mud tonight, I had a thought about how this experience was a lot like building software.

When building software, you’re not sometimes lucky enough to build a system from the ground up.  Normally, you’ll inherit code from developers who have been hacking it for years.  I related this to me working in my room.  I inherited a poorly maintained room.  The joints weren’t level with each other and the mud of the wall wasn’t smooth.  The person doing the work took no pride in the work being done.  The ceiling was also a “hacked” popcorn ceiling.  I say hacked because, instead of using a hopper, the person slung dry wall mud onto the ceiling giving the illusion of popcorn.  The illusion failed though because it looked horrible.

Fast forward to my work in the room last week.  I had to go through and scrap all the excess mud off the wall.  Each wall and joint had to be sanded, and mudded again in order to level everything.  I’ve spend hours of time trying to reverse the effects caused by performing the job incorrectly.

What does this have to do with software development?  Think about when you’re working on a bug in a piece of code, and it’s your first time looking at this code.  How the previous developer left the code is how you’re going to inherit it.  You might have to spend hours undoing the work of the previous person in order to get the code to a state it can be worked with.  Hacks might have to be removed and properly implemented.  Hours will be wasted that didn’t have to be.

When working on new code, do yourself and future developers a favor and leave the code in a state where it can be easily picked up and worked on.  If you’re working on existing code, try to leave it in a better state than it was when you found it.  In the long run, time will be saved, code will be more secure, and a developer will say fewer curse words.