Startups have a phase where the first generation of the product has to make way for the second. In our case, we set out to create
- a wonderful experience for our users
- a faster, leaner front end code base
- a great foundation to build out new features faster
And, those goals meant it was also time to rewrite part of our Kicksend stack.
Rewrites are strangely attractive. Developers love to work on a sparkling clean code base. But in reality, there’s much more to a rewrite beneath the surface. Like all those implementation subtitles and edge cases you took for granted.
Before jumping into a rewrite, start with the business and product considerations, because if a rewrite is the best path then with the right planning and approach, you’ll avoid a lot of pain.
Here’s what worked for us at Kicksend.
Be very clear of your goals
Rewrites can quickly balloon out of control. There will always be the tendency to throw in new features. So it’s important to keep the scope of the rewrite focused. Scope out a minimum viable rewrite – a great place to start would be hitting feature parity with the original version.
We set out to rewrite only the upper levels of our stack, and not the entire application (there was no reason to). In terms of changes, that meant we had three goals:
- a migration to a new database schema
- a refactored, new RESTful set of APIs
- a complete rework of the web application
With those goals in mind, we made sure to hammer out the scope and implementation of each item. We whiteboarded the schema migration, the APIs, and iterated on the new web application’s user-facing design before we wrote a line of code. After which, we split these items up into Pivotal Tracker stories.
From then on, we made it a point not to introduce any features that weren’t directly related to the implementation or didn’t fall in line with our goals, which worked well to curb feature creep.
Simplify
It’s a rewrite. Take the opportunity to simplify.
Each feature and technical decision that made it into our rewrite had to meet the following criteria:
- simplified our technical implementation
- improved user experience
- boosted productivity
1) Cut out Features - Since we measure everything, deciding what to leave out of the rewrite was a straightforward, data-driven decision.
2) Optimized UX - An example of a feature that we did rewrite is “Lists.” In Kicksend, lists are great way to easily send files to private groups of people. We felt that this was a core experience of Kicksend, and we had to nail the user experience. With the rewrite we introduced more intuitive ways for our user to manage their lists and achieved simplification.
3) Swap to Coffeescript – Using Coffeescript made this development simpler and fun, which in turn boosted our productivity. For the curious, the rest of our frontend stack consists of Backbone.js with Handlebars.
On balance, the scope of our rewrite actually turned out to be smaller than the original version.
Get it on production. Now.
Don’t do a waterfall-style “big bang” release. Don’t coop up your rewrite on a staging box, only to be deployed to production on release day. The quicker you can deploy an iteration of your rewrite to production, the easier your life will be.
We spent the first two weeks preparing our code base to accomodate the rewrite on production. That meant a whole bunch of chores like retrofitting our current APIs to write to the new schema, changing up the web application to use the new set of APIs, and migrating over to Rails’ asset pipeline. After all that, we were running our rewrite live in production, in parallel to the original version.
Results
- We continuously deployed (our usual cadence)
- We battle-tested our rewrite in production for a month and a half
- “Launching” just meant flipping a switch
Rewrites are tempting, but can also be deceptively complex. Don’t rush into one. Have a well thought out plan. It worked for us; we launched smoothly and right on schedule.
So check out our shiny new web app, or grab our mobile and desktop apps.
Catch us on Twitter at @kicksend and @derrickko. And join in the discussion on Hacker News.
PS. Sounds interesting? We’re hiring.
Pradeep Elankumaran //
1 Comment 
