Inheriting Bad Code: How to Fix and Prevent it


In this presentation by Kimber Lockhart, as part of the Hack Summit (the virtual conference for programers), she discusses what to do once you’ve inherited bad code. She speaks less about the source of bad code (low budget, high pressure to meet deadlines, company’s decision to hire poor developers) and more on the steps to fix and prevent this code. She does mention that not all bad code is because of technical debt, since for her tech debt comes from a conscious decision to write poor code, but this presentation does address how to get rid of it.

Lockhart defines bad code as any code that doesn’t meet your expectations or the expectations of the company at the time. This missed expectation could be the result of insufficient testing or slow, unstable, and inconsistent conventions. In order to start addressing the poor code, three mistakes that developers often fall into are pointed out.

Big mistake #1: Not learning first and jumping into refactor and fix a system you do not fully understand.

Big mistake #2: The rewrite instinct – rewriting code is not the answer to bad code most of the time.

In order to decide whether to approach bad code with a rewrite developers need to ask themselves a set of questions. Do they know what the new product should do? What is going to be better about this new version? The rewrite could often end up being worse than the original. Is there anough time budgeted to complete the rewrite so that it fits your cost-benefit analysis? In other words will it be possible for 5 engineers to rewrite in 3 months what took a team of 20 to do in 3 years. Finally, in order to decide whether to rewrite, developers should ask whether the whole codebase needs to be rewritten?

She begins by discussing the steps needed to begin the process of fixing broken code. The first step, is to spend time planning and make a list in order to prioritize what needs to be fixed. This should be done in order to justify choices made to stakeholders in the project. In order to prioritize what should be fixed first developers should compare: how bad it is currently, how widespread is bad code throughout the codebase, and does this bad code cause another set of negative effects?  Once this prioritized list of which bad code projects to work on is made, the following methods can be used to improve on the code.

Encapsulating bad code is the best way to move forward with old code. Keeping the old code running but keeping it separate from new and better code by wrapping it in a module will mean no one else can add to it except to fix it. The old code can still be called upon, but encapsulating it keeps the bad code from spreading, and motivates team members who work with the encapsulated code to refactor it so as to meet the rest of the standards.

Next would be to deprecate, even if you think no one will want to copy the bad code it may be better to make sure no one else does so. Asides from flagging bad code, Lockhart recommends also marking fantastic code (for a whole feature) but also but an expiration date on that feature. What was fantastic code 3 years ago is the bad code of today – by writing a test so when the expiration date passes it runs and if the code fails someone has to explicitly look at it.

Typically, when bad code is inherited so is dead code. Lockhart suggests deleting bad code, but doing so with caution. Investing a few hours a week to create an automated system in order to identify code to be deleted would be the best way to go about deleting dead code.

While fixing the bad code that already exists, steps need to be taken to prevent such code from being created again. Lockhart first recommends writing down (better yet coding) your standards in order to make sure there are not inconsistencies in what your standards are and in the code. Asides from this preventive step, she mentions pre-deprecating as a strategy to address the bad code you know you’re creating and make sure that it is known that a decision was taken to write a shortcut. She also warns against making 10% improvements to the framework, as they may not be worth the downside of inconsistent code. Instead, it would be much better when improving the framework to make sure much more than 10% is improved on and worth the additional complexity of dealing with multiple versions in the codebase.

She concludes with a suggestion to follow up after a project, dedication 20-30% of the total time spent working on it to clean it up. This is a good step to make sure bad code does not slip into a project.

Ultimately, she ascribes to the “slow and steady wins the race” method of work as a manner to avoid sloppy code. To watch the full presentation go to:

Filed in: Technical Debt
Load more reviews
Thank you for the review! Your review must be approved first
You've already submitted a review for this item