Summa

Over the last few weeks, during downtimes between meetings and so on, I have spent several hours deleting unused and duplicated code.  By the time I was done I’d killed around 500 lines of code (out of a 20,000 line project).  So you shrank the codebase by a couple percent.  So what? Why would I ever bother doing that?

Well I’ll tell you, deleting code provides a number of wonderful benefits — some purely mental, and some very practical.

1) Deleted Code Never Breaks, and Has No Side-Effects

If I delete unused or duplicated code, there’s no chance that some minor issue with it will cause problems down the road.  If I’ve got to do a big refactoring, or a big branch/merge, or we decide to standardize on a particular way of formatting our source code, I don’t have to worry about the deleted code.  It’s already taken care of: it’s gone.

Recently I was looking at an obscure database table that had grown to an unreasonable size.  It turned out that one of the classes in our project was an entity that we weren’t really using for anything.  However, we’d written a buggy integration test for the class’s DAO.  The test created an object and saved it to the database, but never got around to cleaning up after itself.  Every test run created another line in this table.  By the time we fixed the problem — by deleting the unused class, its DAO, the buggy test, and the database table — we had nearly 1,000 lines in a table nobody needed.

2) The Codebase Is Large; My Brain Is Small

There’s a ton of code out there.  The project I’m on is relatively small and it still has 20,000 lines of code.  I can’t possibly keep it all in my head — but when I look at a method name, I want a shot at remembering what it does without going to the Javadoc or the source.  The fewer things that I have to remember, the more productive I’ll be.  By deleting code I shrink the universe of things that I have to pay attention to and care about.

We’ve all been on projects in the past where a new person joined the team — or been that new person. After learning about the project’s high-level goals and low-level conventions, the new person might pick up a small corner of the project to try and solve a relatively minor problem and get familiarized with the codebase.  I know that in the past I’ve seen multiple classes or methods that all seem to do roughly the same thing.  But only one of them is the right class or method for the job.  By deleting the less-used or inappropriate class or method, you improve everyone’s ability to be productive in your application.

3) Deleted Automated Tests Never Fail, And Run Super-Fast

Assuming that we’re talking about unused code here — there’s no reason to have tests for unused code.  If the only place that a component is being called is its own test, delete the code and the test. This helps eliminate side-effects of testing and inadvertent coupling, too. Oh, sure, we’re supposed to write unit tests that are tightly targeted at a given layer of our application, and stub in mock objects so that we are only testing a particular component.  But I know that when I’m whipping together a quick test I occasionally forget to set up my mocks appropriately, and end up writing a two-line test that takes thirty seconds to execute because it’s communicating with a database, a web service, and an ERP system.

As if that weren’t bad enough, if the database, web service, or ERP system has any changes or downtime, I get test failures in code I don’t really care about!  And while those failures might be utterly bogus, they take precious minutes to track down and trace through.  I could be using those minutes to do something worthwhile.

Additionally, unit test coverage, as a percentage, tends to go up as you delete code — because rarely-used code tends, in my experience, to have fewer tests written for it. So if you delete the CustomerService’s fetchCustomer() method, and then also delete TestCustomerService’s rudimentary testFetchCustomer() method, you’re going to find that in total your test coverage went up rather than down.

4) YAGNI (you ain’t gonna need it)

If you get in the habit of deleting unused code, you’ll eventually find yourself asking whether you really need certain methods in the first place.  Yes, I need a fetchCustomer() method, but do I need a saveCustomer()? All the customer data is coming from the ERP system, I never write to that… Then you won’t write code you’re not positive that you’ll need. And you’ll go out and check to see if there is already code that can solve your problem before reinventing the wheel.  That improves maintainability for your whole application.

5) It’s Not Really Gone Anyway

You’re using source control, right? Right? Subversion or git or even CVS or something?  (If you aren’t, then start — right away!) Then you know that even if you whack a whole bushel of code, it isn’t really gone — it’s still in source control.  It’s just out of your way.  You’ve achieved clarity by removing clutter, but if it turns out that there’s a nugget of brilliance in that deleted class, it hasn’t disappeared forever.  You can always get it back.

Disclaimer: I’m not saying you should go around willy-nilly deleting code or config files that you don’t think you need.  For goodness sake do a sanity check before any deletions.