Coach Rants: On Refactoring

Messy desk covered in office supplies.
Photo by Robert Bye on Unsplash

Hidden Cost of Messy Code

In order to examine the hidden cost of messy code, we must first ask ourselves “Why does the code exist?”. Bear with me here.

  1. To fulfill a business capability.
  2. To communicate how that capability was implemented.
  1. Time spent reading and understanding the code.
  2. Time spent implementing new functionality.
  3. Defects and time spent debugging them.

Reading and Understanding

As anyone that has read through messy code can tell you, it’s not a singularly pleasant experience. Mixed domain language, long functions, gigantic and/or entangled classes, and strange code structures make understanding how it works difficult and mentally exhausting.

Woman stressed out looking at her computer.
Photo by JESHOOTS.COM on Unsplash

Implementing New Functionality

This is the obvious one, right? Developers write code. However, what’s not always obvious to people that don’t ship software is the profound difference between adding new functionality to well-factored and messy codebases. Well-factored code where everything has a purpose, place, and clear intent is code that’s easier to modify, and test.

Warehouse with spotless floors.
Photo by Ruchindra Gunasekara on Unsplash

Defects and Debugging

This is really just another way of saying reading and writing code, but this time a customer is being impacted. All of the above still applies.

  • If it’s hard to read the code, it will be more difficult to find root cause(s).
  • If it’s hard to modify the code, it will more difficult to fix the issue.
  • If it’s hard to test the code, it will be more difficult to simulate the issue.
Large cockroach on a branch.
Photo by Robert Thiemann on Unsplash

Beware! Pitfalls Ahead!

We’ve talked about some of the reasons to keep a clean code base and how refactoring is a critical tool for that function. Now here’s a curveball. Refactoring isn’t always the answer, and is occasionally a bad idea. Here’s some pitfalls to beware as you are out there cleaning your source code for the greater good.

Over-cleaning the Code Base

I know I was just talking about how important it is to keep the code base clean, but there is such a thing as too clean for a particular context. Warehouses and operating rooms should both be clean, but they have different standards for what clean means in their context.

Spotlessly clean operating theater.
Photo by Arseny Togulev on Unsplash

Large Scale Refactor

Your tech lead determines that a large scale refactor of the system is in order and it will take 3–6 months in order to complete. Your customers are distraught, escalation emails are flying, and the team is giddy because the code has been degrading at an accelerated rate and they’ll finally have a chance to “do it right”.

Big broken rock on a river bank.
Photo by theverticalstory on Unsplash

Hardening Sprints

A smaller-scale version of the Large Scale Refactor, a hardening sprint is a smell that we are not baking quality into our development process. If we schedule time to go back and add tests, clean code, etc. we are putting time and cognitive distance between the developers of now and the developers that actually wrote the code.


Rant over. That’s an overview of the costs of messy code and pitfalls to avoid in the search of keeping it clean.

  • It’s important as developers to be able to communicate why cleaning the codebase is a critical and necessary function.
  • Messy code bases are slow, expensive, and dangerous.
  • Teams of highly trained engineers are expensive. Optimize for their/your time.
  • Cleaning the codebase generally has slim/no direct value to customers. Bake refactoring into your value-adding changes to make the cost easier to bear for feature-happy end-users.
  • Any change to the codebase carries cost and risk. Make changes in order to maximize value throughput to the customer while minimizing risk.
  • Refactoring has some pitfalls to be wary of, but keeping them small, continuous, and relevant reduces the pitfalls to pinholes.




Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Nathan Nicholson

Nathan Nicholson


Senior Release Engineer and Value Stream Architect at Netlify