Friday, January 11, 2013

Taking it out is better

As developers we spend a lot of time writing code.  Most of this is adding new features to a product, the rest is spent changing a product to use a new API.  Seldom is it to go into a system and clean up all the relics lying around in the code base.

When you switch to the new shiny API you seldom remove the old code files that talked to the old API because you may need to switch back to the old API in a real hurry.  You comment out the code or put in a conditional statement thinking that you will come back and remove them later on when you aren't so busy. This is all well and good except for one thing you are always busy. 

Over time these code relics pile up and pollute a code base.  Remember the developer that put in the "if statement" on line 12 of foo.cs?  Well he took a new job and now no one knows why that relic exists. The knowledge left with that developers and now we have a liability.  Most developers are willing to let sleeping dogs lie.  If everything is working don't make changes to the code because change means bugs and bugs mean more work.

Not cleaning up code over time causes more work.  You may have unit tests that were written against those old logic branches that are now invalid and out of date.  They could be a red herring in trying to figure out real problems in the code base.  The worst part about this is that it can be prevented with just a little work when you are changing the code.

Take the time to remove the code that is no longer needed.  If you need to roll back to the old way of doing things you use your source control to get the code back.  Take the time to prune useless unit tests.  If a test is not meaningful either change it so it is or get rid of it.  Just by doing these simple things code can be made so much easier to maintain and update over time. 

No comments: