Code Practices: 5 Strategies for Dealing with Bad Code

There is a lot of discussion these days about good code practices, but, let’s face it: With the expectation for more applications at a faster and faster pace, bad code happens. Everyone has seen it, and everyone loves to complain about it, but it’s what you do to fix bad code that matters.

There are myriad approaches to dealing with bad code. You could try to fix it yourself. You could ask whomever wrote it to fix it--if he or she is still around (and working with you). You could discard it entirely and rewrite it from scratch.

Which of those approaches is best when handling bad code? Here’s some guidance.

What Is Bad Code?

First, let’s define what bad code is. It’s obviously a subjective concept; what counts as bad code to one developer might be perfectly good code to someone else.

Still, there are several common characteristics that constitute what most of us would call bad code:

Strategies for Fixing Bad Code

What do you do when you encounter code that is subject to one or more of these flaws? Assuming you have the power to modify or reject the code, here are strategies you might choose to take.

1. Have the original author rewrite the bad code.

You can, of course, simply to ask the person who wrote the bad code to fix it.

This might seem like the most obvious and rational thing to do. It’s straightforward. It’s a way to educate the person responsible for the problem and prevent the same issues from recurring in the future.

However, asking the code’s author to rewrite it doesn’t always work--for two reasons. One is that the author may simply no longer work with you. In that case, unless you have an exceptionally accommodating former colleague, there’s little chance you’re going to get him or her to rewrite the code. The other challenge is that telling someone his or her code is bad is a delicate issue. Sometimes, it’s not worth spending the social capital. Other times, it might backfire by leading the author of the code to feel criticized and isolated, leading to more problems in the future.

So, if you can reasonably have the author of the bad code fix it, take that route. But realize that this isn’t always possible.

2. Rewrite the bad code yourself.

If the author can’t or won’t rewrite the code, you can take it upon yourself to fix it. That’s usually a less socially fraught practice. And you can do it whether or not the original author is still around.

Of course, the challenge here is that rewriting the code yourself takes time--not only the time required to do whatever work you have to do to fix the code, but also the upfront time/cost of having to figure out what the code was supposed to do, why it’s not doing it well and how to fix it. In some cases, this effort may not be worth it; you’d be better off just rejecting the code.

3. Reject the bad code.

On that note, it may be in your power (if you are the manager of a software project at your company, for example, or the “benevolent dictator” of an open source project) to choose simply not to use the code at all. You can tell the author it doesn’t satisfy your quality requirements and/or is not significant enough to include in the codebase.

Obviously, if the code is for a critical feature, you’ll need to replace it with new code. You’ll have to decide whether it’s really worth the reject in that case.

But if the code implements non-critical functionality, simply rejecting it might be the best approach (especially if you are not worried about how the rejection will impact the code’s author and your ability to work with him or her again).

4. Keep the bad code, but note its badness (and fix it later).

A fourth approach is to use the bad code, at least in the short term, but make sure that your commit notes and source code comments make clear that the code is imperfect.

This isn’t a best practice because it doesn’t address the core underlying issue in the code. But it’s a tradeoff you may need to make in situations where you don’t have time to fix the problem, but you also need the code in order to avoid a delay in your development operations.

In a perfect world, you’d always set (and meet) a deadline by which you intend to fix the bad code--unless you know that the codebase itself is going to be overhauled and the bad code discarded at a certain point, in which case choosing to use the bad code temporarily might be just fine.

5. Destroy everything and start from scratch.

A finally strategy--and the one that may serve you best if you are constantly dealing with bad code--is simply to throw your entire codebase in the trash bin and rebuild everything from scratch.

You need not be a programming expert to know that this approach is an extreme one. And it may not be worth all the trouble if the bad coding problems are caused by individual developer choices, rather than the codebase itself.

But sometimes, especially when you’re dealing with legacy codebases written by developers who retired from the company and moved to Florida before you even started, bad code keeps cropping up simply because the codebase itself is flawed--or at least not up to modern coding standards. If that’s the root of your issue, then scrapping it all will not only relieve you of your bad code issues, but also give you opportunities to embrace more modern technologies (like a microservices architecture or a better programming language) when you rebuild.

Conclusion

There’s no “one dumb trick” for fixing bad code. It requires work, and it’s often a messy process -- both in technological and cultural-social terms. But as any seasoned developer knows, addressing bad code in one way or another is something you’ll want to do, because if you don’t, your problems will snowball until your application crashes at 2 a.m. and no one can fix it because the code is impossible to read.