Testing a Ball of Mud 🚛

Jul 16, 2021 3:19 pm

Happy Friday!

I gave a talk for a conference late last month and there were 195 attendees! I gave a talk on a topic I bump into all the time which is when there is a codebase that is a clumsy, awkward codebase, and how do you start testing it so you can fix it.

My talk covered a number of things but I wanted to take a little time here to explain it as well, so here are some major points that I think people have to consider if they're going to fix a messy codebase.

Smart People Made The Mess

That might sting a bit, but it's very true. Smart, well-intentioned teams build the codebase that is unwieldy. Some of you might have moved to microservices recently, only to realize how true this statement is. Instead of having one big codebase that is hard to deal with you wind up with 20+ codebases that are hard to deal with and really hard deployment problems.

Anyway, why this point matter is that fixing this stuff isn't a matter of being smart or not.

It is about choosing to do something different and sticking with it.

Different feels weird. Different often feels wrong. The problem with listening to our gut is that our gut is happiest doing what it already did, which happens to be building a ball of mud. So, to get out of this teams have to take a leap to do something they believe won't work or is completely impractical.

Start With These Two Types of Tests

First, I want teams to build a set of tests that confirm everything is operating correctly. No point in writing code on a system that isn't operational. It's amazing how tolerant groups are of unstable or non-operational systems. Have the tests run continuously and fix things as they come up. Ignoring the test results is a great way to keep struggling.

At the same time start unit testing. There are better tests to write in terms of making sure things are correct, but a funny quirk of balls of mud is that they almost never have tests. That also means that the teams have no practical experience testing software. Unit tests are a cheap and low-risk way to develop those skills. Skipping this skill-building part can stall progress for over a year!

Clean As You Go

As those tests start passing there is an opportunity to clean things up as you go. Don't turn these efforts into separate projects or work items. Testing and cleaning things are now part of the way the team works. By putting them off to the side, the efforts end. If having a ball of mud isn't bad enough, adding in legacy tests is madness.

So with tests passing, make small improvements. The tests will provide feedback for correctness and design as the tests will get easier to write and maintain. I never promised that the codebase will get cleaned up quickly, but this works. The nice thing is that approaching the effort from the perspective of habit and routine means other projects benefit from it as well.

Anyway, those are a few points I thought I'd highlight that I think are really important in an effort like this. If you have questions or want to talk more about it, let me know!

Here's the video!

Here's my weekly update for July 16th, 2021...

🗒️ Want to Get More Interviews?


Ever wondered why you don’t get an interview at some companies?

The answer is that your resume wasn’t good enough.

In this article, I will take a few moments to explain why that is and a few things you can do to stand out more.

Click here to read more

🗒️ 3 Alternatives to Saying, “I Don’t Know” In Interviews


Eventually you won’t know how to answer a question in an interview.

In this article I walk through three alternatives to saying “I don’t know” that give much better results.

Click here to read more


Ryan Latta