How to deal with a Big Pile of Mud

Last week I talked about where those big, unwieldy code bases come from. They don’t appear out of nowhere, and no one ever plans to create one. Defining a problem is great, but what is one to do? How will you deal with the Big Pile of Mud that you inherited?

It’s tempting — and I see this temptation indulged all the time — to stamp your feet and bitch and moan about the big mess you have. I am sorry to say that I’ve been a staunch complainer in these situations in the past. How could anyone have been so foolish? No developer could actually be this bad, right? What were they thinking?

Go ahead and indulge. Feel all the feels. But keep it to yourself, get it all out, and get over it. Because the first step to addressing the problem is to accept that you have the Big Pile of Mud.

Step 1. Embrace the mud

Instead of giving in to the anger and blame, it’s important to realize that this Big Pile of Mud works and puts food on the table for you and everyone in your company. Sure, it’s a mess, but it pays the bills. You might hate it. It might make you frustrated and angry. But you need to just swallow all of that and move on with the job of fixing the pile and making the mud do new things.

Once you are past all that, the next thing is to remember that the best thing to do when you are in a hole is stop digging. Job one is not to make things any worse than they already are. Don’t add another layer of depth to that huge, nested if statement. Don’t add 120 more lines of code to that God class. Don’t follow those old patterns of coupling things together and making one thing do fourteen things and mashing concerns together. In other words, don’t make any more mud.

Step 2. Apply the Boy Scout rule

The first standard you should set is to always apply the Boy Scout Rule to your code. That is, always leave it a little better and a little neater than you found it. For instance, if you find code that isn’t formatted to the company’s formatting standards, format it properly. If you find code that has crappy variable names, change them to be more descriptive. If you find code that has lines of code that do seven things, refactor out to explaining variables. Set a policy that the time spent improving code as you run across it, even in little ways, is well worth it.

Also as a rule, always delete commented-out code and other dead code. For reasons I have never quite understood, many developers like to comment out code instead of deleting it. I guess they think they’ll need it later? I don’t know. In any event, if you run across commented-out code, just delete it. If you do end up needing it, it’s safely there in your source control repository. Can you tell this is kind of a pet peeve of mine?

Step 3. Refactor high and low

Next up — refactor judiciously. The first refactoring you should do is to pull out code that is inside if statements and organize it into separate procedures. Almost every huge routine I’ve ever seen is made up of a large number of nested if statements. You can get an easy win by highlighting all that code inside each branch of each if statement and creating a separate procedure for it. This alone will start simplifying your code base. By the same token, never write more than a few lines of code inside an if branch in any new code you write. 

And for all new code that you write, commit to putting all new logic into separate classes, and call the methods of those classes instead of just piling code into ever larger methods. Apply the single-responsibility principle as best you can, and try to keep each thing that needs doing separate and uncoupled. This is probably the most important “stop digging” action you can take. Just refuse to pile up those methods that have more and more nested code. 

Step 4. Break up dependencies

Finally, after applying these basic, relatively safe refactorings, endeavor to be a bit braver and start refactoring more deeply. Continue to break down functionality into classes, and write unit and integration tests for these new classes. You should make sure that all new code you write is testable. Start breaking dependencies by using dependency injection. This too is critical to stopping the digging because its use will stop dependency coupling in its tracks. Certainly apply the principle to all of your new code, and slowly start refactoring your existing work. 

Ultimately, dealing with a Big Pile of Mud involves a commitment to breaking old, bad habits and implementing new, good habits. You won’t always be able to fix a bug in the best possible way, and large compromises may sometimes be necessary when adding new features. But if you keep your head up and your eyes open, that messy, embarrassing code base can both improve and continue to pay your salary.