It might sound paradoxical, but in general, writing more code is easier than writing less code that accomplishes the same goals. Even if your code starts out clean, compact and beautiful, the code that is added later to cover the corner cases nobody thought of usually takes care of the code being well designed, elegant and beautiful. Agile programming offers a solution, namely constant refactoring, but who has time for that? That’s why I occasionally give myself the 10% code reduction challenge and I encourage you to do the same.

What is the 10% code reduction challenge? It’s pretty simple, actually. All of us have that piece of code that bugs us and that we try to avoid looking at. You know, the one that whispers to you “make me beautiful” and that everybody dreads going near because it’s so convoluted and frankly, a mess.

Now set some time aside - yes, I know, the time I just mentioned nobody has - and rework the code. You may have to refactor parts of it, redesign other parts of it so you can accommodate the corner cases in the main flow of the code and delete the parts of the code that are in there, aren’t used anymore but everybody is afraid to touch.

The overall goal is to achieve a 10% or greater reduction in code size with a similar increase in code quality by meaningful refactorings. So, no calling all variables i,x,z,y or something like that.

Doing this has benefits, both short-term and long term:

• The obvious benefit is that you improve a piece of code that is very likely an endless source of bugs, due to the fact that no developer wants to go near it. That alone should be a big benefit because you can actually spend more time on working on tasks that matter instead of partaking in the weekly chase for yet-another-bug.
• Reworking a piece of code with the explicit goal of making it smaller tends to further your in-depth understanding of the language and the libraries you’re using. You’d be surprised how often I’ve written code that I can throw away and replace with a call or a few calls to library functions. If you’re working in C++, the Boost libraries will often contain building blocks that make your life much easier.
• The reduced code most often makes the intent of the code much clearer once it’s been redesigned. That’s a massive benefit down the line if you have to go back to the code after a while. And trust me, you will have to if you work in the same team or on the same project for any reasonable amount of time.

Took the challenge? Let me know in the comments!