Every project eventually hits a point where a big change needs to be made, and it’s going to break everything. And you’re going to be the one stuck putting it back together.
Whether it’s a language or tool change that causes your application to no longer compile, a third-party SaaS service change that breaks features throughout your app, or just a big refactoring, eventually you’re going to have to bite off more than you can chew. After having been faced with situations like these many times, I’ve developed a coping strategy.
Here’s how I tackle these big hairy changes.
1. Get a Clean Test Suite
Don’t try to upgrade things with an unstable foundation. Get your tests clean first. Having a clean test suite before you begin gives you a known good state. This assurance is valuable, since later you’re going to use the tests to validate that you’ve done things correctly, and you can only do that if the tests are valid.
2. Make it Compile—By Any Means Necessary
When you make a large change, it’s likely that the app won’t even compile. (This isn’t quite the same for interpreted languages, but the idea is sound.) And when your codebase won’t even compile, you don’t have a lot of feedback. Get it to compile–even if it doesn’t work.
Feel free to comment out whole classes and methods. Your immediate-term goal here isn’t to “make it all work.” (You want that eventually, but it’s too big a goal to focus on right now.) Rather, your goal is to get better, more accurate, and more targeted feedback about where to work next. So comment out all the methods until it compiles.
This gives you at least one codepath that can run through your code. If it doesn’t compile, you don’t even have that. It doesn’t matter that the codepath that runs is extremely short (e.g. because your app aborts immediately), since it gives you a place to start (e.g. wherever the error came from.)
But don’t fix it yet. Now that you’ve got a specific single failure to work on, you’re positioned well to proceed. But there’s still a bit of mise en place to do first.
3. Get Your Test Suite to “Run”
Make sure your tests will run. Surely, they’ll mostly fail, but that’s okay as long as the test suite can at least boot and try to set up each test. Every error here is okay. Each is a targeted, specific thing to fix.
4. Continuous Integration
If your test suite will at least boot, then it’s time to get your continuous integration updated, too. As tempting as it can be to work locally on your machine, I’ve found that test suites often just take too long to run. Getting a second environment running quickly can provide better feedback, and anything that speeds up your cycles is good. Getting that rapid feedback cycle going as quickly as possible is valuable.
5: Finally…Finish the Job
At last, five steps in, you can start to fix things. There’s no sugar-coating it. This is the hard part. It’s often a grind, and it can still feel overwhelming.
But if you’ve followed the above steps—and you have good test suites—you’ll at least be equipped to attack the problems one piece at a time. I’ve not yet learned any better way to attack a big problem than to break it down into smaller problems.