We've all read articles that use way too many words to get their point across. Or books that give way too much detail about a scene before getting to what's actually happening. I've become an expert in skimming headlines and paragraphs because it's all too common. Nobody has time for rambling.

What if I told you your team is probably doing something similar in your codebase? What if I told you it was probably costing you hundreds of hours of work?

I am ruthless about removing all code that isn't necessary. If there's a case being handled that I'm not totally sure will happen, I remove it. If there's a method that I wrote that I didn't end up needing, I remove it. If there's a block of code that is more verbose than necessary, I simplify it.

Unnecessary code can happen in a few different ways:

• When a programmer's strategy changes during the life of a task, and relics of the old approach stick around.
• When a programmer comes up with a solution that is more complicated than it needs to be.
• When a programmer tries to anticipate future needs and adds unnecessary functionality that may or may not be needed in the future.

These may seem like minor details, but if left unchecked, the cost can compound and become enormous. Here are some of the underlying mechanics behind this cost:

Comprehension speed

The number one goal of your code is to make it as fast as possible for another developer (or future you) to come into your code and understand what's going on. The faster they can understand, the faster they can be productive.

If you leave code that's over-complicated or not necessary, you add the overhead of your colleague trying to reason about what that code does and why it's there. There's no hint to them anywhere that you left it in by accident, or that you were saving it for some future use, or that you didn't have time to simplify it. They'll need to trace through your code repeatedly until they can convince themselves that that code is in fact not needed.

If there are many instances of leaving unnecessary things in your code, this confusion can grow exponentially and can end up costing your colleague enormously! They'll have to balance all the pieces in their head until they can finally untangle things and convince themselves of the way it works.

It would be much better for you to have removed the unnecessary code in the first place.

Extension

Imagine one of your colleagues (or future you) doesn't give your unused or overcomplicated code the diligence it deserves. As a result, they don't realize that it's not necessary. This is where things get expensive.

They've been tasked to build something in the same area of code as your unnecessary code, and they include your unnecessary logic in their extension. This exponentially increases the problem! Now a future colleague that looks at all of this code will need to reason about your original unneeded code, the new extended code, and how they integrate together in order to figure out what's going on. Of course, if this future colleague extends it even further, the problem multiplies again.

I hope you're seeing how this can create a dangerous, exponentially growing problem in your code.

Learning

If a colleague is a junior developer, someone new to your technology or someone new to the area of code you're working in, they may not have the experience or knowledge required in order to realize that parts of your code are unnecessary or overcomplicated. They may take the bad example and assume it to be the proper way to do things.

Similar to the previous example, this can be expensive if this dev then goes around and sprinkles in all this extra unneeded complexity around your codebase. If there are multiple people learning from your code, these habits can spread like wildfire. This is enormously expensive to catch and re-train.

It's better to make sure that all your devs have proper examples to learn from.

A better way

Imagine coming into a file and the code feels like it was written specifically to tell you what it's trying to achieve. There's no need to trace through lines of code repeatedly to reason about what the results of a block will do. There are no cases being handled that make you question “Oh do we handle that case? I wonder why…”. Longer blocks of logic are simplified into well organized expressions.

This is the type of gift you can give to your colleagues by being diligent about simplicity.

My strategy: When you're ready to submit your code, open your code up in your favourite diff tool (I use the one in Visual Studio Code), and repeatedly go over your code, making fixes and refactors to clean things up until you get through the whole thing 3 times without needing any changes.

Conclusion

Even though it can seem like no big deal to leave a tiny bit of unnecessary or overcomplicated code in your codebase here and there, it can be enormously expensive over time. On the other hand, tiny gains compound for huge results. Code with a high signal to noise ratio enables your team to move faster than you thought it ever could! Be ruthless about simplifying your code!