You have been working on this new feature for days. Suddenly you are stuck. You are faced with a problem that you haven’t thought of so far. After some painful hours of blood, sweat, and tears you finally have a Eureka! moment: a brilliant idea that will solve your problem in a very elegant way, but it will take a few days to implement.

After you’re done, you feel overjoyed: what a nice solution, what a beautiful design (you even used template metaprogramming), well-crafted doxygen comments, no compiler warnings and — needless to say — all the unit tests pass. You walk around the office with a smile on your face, you want to tell everybody what marvels you have achieved… alas, the third person you bump into tells you that the problem you have solved is in fact no problem at all — neither was nor is. Perhaps in the distant future, but surely not today.

Your heart is pounding, you feel dizzy, you feel sick. You try to defend your work, but your colleague’s arguments are compelling.

What to do, you ask, after having gone through so much pain and effort; what to do with this beautiful code? I tell you what: admit defeat and take it out again, period.

We’ve all been there. Sometimes it’s just a few lines, sometimes many classes, worth many person-days: It’s not really required for the product, but it is already implemented. In such miserable moments, you can add the most value to your project by deleting what’s not needed. I know it is hard, due to what psychologists call cognitive dissonance, but it must be done. Remember Antoine de Saint-Exupéry’s words?

“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”

Usually, programmers have little difficulty accepting software minimalism principles as advocated by agile development practices like Extreme Programming (XP). As Ron Jeffries notes “Always implement things when you actually need them; never when you just foresee that you need them”. Clearly, every feature requires time to write, document, and test. And according to the YAGNI principle: “You Ain’t Gonna Need It”. But what if the time and money is already spent? Why not keep the code, it surely doesn’t harm?

The sad truth is that it does harm, even if it is already written, tested, and documented. The more code you have, the more complex a system becomes. Every additional line of code makes a system harder to read and understand, especially for new team members. It makes the system a little bit harder to refactor and maintain. Maybe someone wants to reuse your feature in another project, but rather reinvents the wheel because he doesn’t want to read and understand all that extra code. Further, such unnecessary code often leads to more unnecessary code in the same or other parts of the system.

Let me put it this way: “Anything that’s not worth implementing is not worth having in your code base”.

You needn’t (and shouldn’t) throw your code into a black hole, though. Push it on an experimental branch, or tar it up and put it in your project’s Wiki. This helps you to get over your loss and if you really need it someday, it’s there for you to be resurrected. Until that day comes, it’s best for your and your teammates if your code rests in peace.