How do you know it’s time to rewrite code?

By Calvin Morris

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.

Big Issues

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

Once we started entertaining the idea of a rewrite, we took a look at the scope of the project. We determined that the back-end was super solid, but the front-end is really where most of our problem areas lived. Specifically, it was a mixed bag of Javascript that was becoming increasingly difficult to maintain.


It’s important to clarify that, for us, deciding to redo the front-end did not mean refactor. We wanted to end up with a high level of comfort at the end, so that meant our developers wanted to touch everything. Since the new design is a pretty big departure from what we’ve got now, we chose to completely scrap the existing JavaScript and the stylesheets.

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, or tweet us at @ballparkapp.

Login to your Ballpark Account

You can log in to your Ballpark account at the domain you chose when you first signed up, or were invited to Ballpark.

Please contact us if you don't know your domain.