The joy of removing code

I am working on a project right now where my main task is to remove code. “What? I thought developers were supposed to add code, not remove it?” Well in some cases removing code actually can help a project. Some reasons to remove code: if the code doesn’t serve any purpose, if it isn’t executed, if it is for an edge case that never happens, if it has been superseded.

Removing code is easier with automated tests, but I still find myself using a combination of automated tests, manual testing, and the find command. (This codebase is ruby, if I was using java I’d use the type system.) It’s painstaking work, but will be good in the end.

My steps for removing code:

• Start with a plan and and end goal in mind. Otherwise it can get overwhelming if you are dealing with a system of any size.
• Create a feature branch
• Identify one piece of code you’re going to either remove or keep
• Make sure you know where it is called. If it isn’t called anywhere, remove it.
• Remove any tests and associated functionality (views, helpers, etc).
• Examine any state managed by the code for removal (database tables, etc)
  • Oftentimes I’ll just note that this should be removed in a few months, and focus on hiding the UX. It’s a lot easier to resurrect UX if you make a mistake than it is a dropped database table.
• Commit the changes with a good commit message.
• Fan out from there and see if you need to add anything to your list.

Take your time, don’t rush it.

Code that never runs can’t have any bugs, and is super fast. Think about removing some code today.