When every commit requires fervent prayer, it might be time for a rewrite.
This is how we decided to overhaul our SaaS app. When I say redesign, most folks think I’m talking about look and feel. The redesign of Ballpark is about much more than layout updates and color choices, though. We want everything about Ballpark to be better, not just different, and that includes the code base it’s built on.
I’m sure a few of you read the title and thought, “Um, it’s never time to do that because that sounds horrible and scary and expensive.” In a way, you’re right. It can be horrible and scary and it is definitely expensive, but sometimes it’s the best way forward. Here’s how we came to the conclusion that it was time for us to do things differently.
Like all product companies, we want to be able to bring features to our users quickly, efficiently, and confidently. This honestly was our primary motive behind the decision to re-evaluate the code. We bought the product, so naturally, we inherited a codebase that we didn’t write.
Slow As Molasses in January
Inheriting code isn’t a huge deal, but imagine it this way: you’re in college, and you miss a month’s worth of classes (your teacher doesn’t take roll or something, so you aren’t going to automatically fail – chill out). But there’s a huge exam coming up and you need to know everything the class covered while you weren’t there. You ask to borrow a classmate’s notes, but he’s a really big hipster and only writes things on parchment paper with a feather-tipped pen. In cursive.
You both speak the same language, and you both can read, so this should be fine, right?
Yeah, but even being comfortable with another’s handwriting, versus your own, will slow you down a little. And it’s going to slow you down a little every time you look at his notes.
Like, in perpetuity.
All those little slow-downs add up. In our case, these cumulative code slow-downs were part of the reason for the re-write.
Testing The Waters
Another big problem was the lack of testing built into the code. If you haven’t worked with an application before, tests are ways of knowing if you broke something when you make a change to the code. A good test suite will automatically run when a commit happens, then tell you if you broke something, and where you broke it. Not having tests contributed to an incredibly high ramp-up time for developers and a low level of confidence in pushing new features.
As I’ve mentioned before, we’re a small team and we often have to bring in extra developers to help out. If we want to set them up for success (and in return, save ourselves some money), they need to be able to dive right in and start contributing in a week, or less. We don’t need a bunch of folks all up in the code like:
This is how we do it
We also enlisted some Rails pros to help us implement those tests I talked about earlier. We’ve already got a much better process for scaling our development firepower, but that’s still a work in progress.
Going forward, we’re going to have a method to the madness, and a much higher level of confidence in the code we write.
Timeline and cost
This rewrite has not been easy. It has not been fast (read: ‘spensive). We think it’s worth it. But the most important part of deciding to do a code rewrite is having long-term commitment from the folks that matter. Your stakeholders have to be convinced of the importance and the future value of this Herculean task, and then you need to be prepared to justify yourself along the way.
We’re super excited about the foundation we’re laying for making our product better – and the ability to make it better, faster – so that we can deliver a delightful experience for all of our users.
I didn’t want to get too far in the weeds with all the decisions we’ve made with our codebase so far, but if you want to talk details you can reach me at firstname.lastname@example.org, or tweet us at @ballparkapp.