I just read a good post from Blake Smith cleaning up your code.  This is a subject that doesn’t get enough attention from developers.  I can’t tell you how many times I’ve been looking through a code base, mine or someone else’s, and found reams of old, unused code just hanging around.  There are partially implemented features, blind alleys, and dead wood that was never removed.  The worst, in my opinion, is old code that was commented out and not deleted.  If this is your code base, remember what source control is for.I agree with Blake’s assertion that deleting code is fun.  When I whack large chunks of useless cruft, overengineered junk, and commented out crud, I know that I’m making the code simpler.  In turn, that makes it easier to understand, easier to debug and possibly faster to execute. Moreover, while I’m in there looking for code to clean out, I may find opportunities to refactor code that needs to remain.

The problem that we run into frequently is justifying the time required to do this to management or clients.  If they don’t understand software development, this idea might seem like a waste of time.  It doesn’t add new features, so why waste time on it?  My solution is to try to build time into every task to clean up code as well as write it.  Imagine how well maintained your code could be if you cleaned out unnecessary bits before adding new features.  If you have to add a little business logic to a module, clean the place up first.  No tweaking that controller until you dust out the corners.

Can you manage this at all times?  Probably not.  We all have deadlines and emergencies that come up.  As a regular practice, I think that it has some value.