The Dead Code Manifesto

We believe the removal of unused code should be a fundamental practice of professional software development.

We test our code, we track our issues, we review our team members' changes, we even define our own style guides. Yet why do we allow unused code to build up in our projects? "Because it's harmless", you may reply. Well, we firmly disagree. This manifesto explains why.

Clutter is Complexity

Software development is not an easy task. Many of us have witnessed the horrors that projects can become. Years of technical debt, feature creep, changing requirements and failed experiments all too often lead to a mess of complex code that even the senior developers on the team shrug their shoulders at.

While removing unused code is no silver bullet in the fight against complexity, it is a weapon we can use to make our lives that little bit easier. The odds are stacked against us. Our projects will grow, and so too will the size of our teams, and with that growth comes the inevitable complexity. It's an uphill battle on an ever growing mountain.

As projects grow, so too can the difficulty of refactoring code. Typically older portions can present more challenges: the author is no longer with the company, there aren't any tests or it was written when some convenience APIs weren't available - the reasons are many. Unused code also tends to be older code, therefore removing it could potentially save both time & money, and you from a headache.

Another instance in which the complexity of unused code rears its ugly head is when transitioning to a newer version of a language. For statically typed languages such as Swift, this can be even more frustrating as a single line of code can block the whole project from compiling successfully. Removing all unused code from your project prior to the upgrade could save you a significant amount of time, especially if any of the unused code is particularly resistant to being ported to the newer version.

"You ain't gonna need it"

"You ain't gonna need it" (YAGNI) is a principle of extreme programming that states a programmer should not add functionality until deemed necessary.

Software development is a responsive practice, we often don't set our own direction or define our own requirements; we develop software in response to a need put forward by others. At a moments notice requirements can change, or direction may shift. Even when we do have the luxury of control over these things, external influences can just as easily be a force of change.

That's why we believe YAGNI is such an important principle, we also believe the same applies to the removal of unused code. If you ever find yourself saying, "But I might need that", then stop. Let's be pragmatic about this. The likelihood that you're really going to need it is low. The likelihood that you're going need it in its current exact form is even lower.

The amount of code in question should not be a factor in deciding its fate. Small portions of code are easily replaced at a time, when, and if the requirements for it become more clear. As for larger portions of code - why carry such a heavy burden that you might need? We're fortunate as software developers to use source control that tracks every single change we make. Searching through commit history to find deleted code is trivial. Imagine if soldiers could call upon items they might need at the flick of a wrist - I'm sure they'd welcome the lighter pack on their backs!

The pragmatic thing to do is remove the unused code and move on. Carrying with you the burden of unused code is just another potential avenue of distraction. Eliminating dead weight is a tenet of agile development.

Build Speed

Waiting for software to compile is the bane of many developers. Some programs are small enough that it's not a major issue, others are so huge that compile times are long enough that you can switch your attention to another task while you wait. Though most seem to inhabit a grey area between 1-10 minutes that doesn't give you much time to do anything else except maybe twiddle your thumbs, or check the tech news for the 10th time already that day.

Removing unused code probably isn't going to drastically reduce your overall clean build speed, yet every little helps. One area it can have a more meaningful impact is incremental compilation. Swift keeps track of every type that a source file exports and uses. If you make a change to the file containing type A, Swift will also need to recompile files that depend upon A. Removing unused code has the added benefit of removing dependencies between source files, thus reducing redundant incremental recompilation.

But Ultimately, Pride

Pride is what motivates many of us to do our best work, even at times of frustration or disagreement. Like a chef keeping their work surfaces clean, or the enthusiast obsessively polishing their car, developers have their own ways of taking pride in their work.

We choose to make keeping our projects free of unused code one of the ways in which we show our pride.

Take pride in your work. Keep it clean.