Why RJMetrics 'rewrote' its code - Technical.ly Philly

Dev

Oct. 17, 2014 10:12 am

Why RJMetrics ‘rewrote’ its code

A behind-the-scenes look into RJMetrics' most significant product update yet.

What RJMetrics looks like to a customer.

(Screenshot courtesy of RJMetrics)

This past summer, RJMetrics launched a new version of its business analytics product. A project one year in the making, it breathed new life into software that was originally coded in CEO Robert Moore’s attic.

“Some of the smartest engineers on the planet kicked my code from the attic to the curb and built a next-generation RJMetrics that will launch us, and our customers, into the future,” Moore wrote in a blog post announcing the launch.

Kicked it to the curb? Let’s get this straight — it wasn’t supposed to be a code rewrite, at least not from the outset, said VP of Engineering Chris Merrick and UX designer Matt Monihan.

The project started out as two separate initiatives to update different aspects of the RJMetrics product, which collects, consolidates and optimizes data from ecommerce and software-as-a-service companies so that those companies can churn their own data with charts and graphs.

For example, a customer can use the software to look at revenue over time, the number of leads coming from various channels and how much those leads are costing or the average time between customer orders.

While the data analysis aspect of RJMetrics is the most public-facing, that’s only a quarter of what developer work goes toward, said spokesman Tristan Handy. The rest of the work focuses on the “consolidating and optimizing” data piece, which involves cleaning the data up and getting it ready for analysis (that tool, the “Transformation Cluster,” is built on top of Amazon Elastic MapReduce) and storing it in the RJMetrics data warehouse (they use Amazon RedShift).

That’s one thing that sets the company apart from its competitors, like West Coast firms Looker and Tableau, who don’t store customer data in their own data warehouses, Handy said. Instead, those companies have customers with an in-house team to build custom solutions that will consolidate their data.

Advertisement

Echoing Moore, Merrick talked about the product updates as building a “stronger foundation for the future.” The changes were driven by what they’d heard from customers and their in-house analysts.

Here are the two projects the RJMetrics dev team embarked on that eventually became the code rewrite:

  • Improving the user interface of the report builder and offering more options on it for data analysis.
  • Rebuilding the Transformation Cluster so it could handle more data, which is important for both attracting bigger customers and for holding on to current customers who are growing. As Monihan put it, “A lot of customers grow with us. We don’t want them to ever grow out of us.”
rjmetrics report builder

The RJMetrics report builder. (Screenshot courtesy of RJMetrics)

 

Once the team had finished those two projects, they realized they’d rewritten about 80 percent of the code, Merrick said. (This is also where Merrick and Monihan point out that code rewrites are a touchy subject and that the RJMetrics product update was less an overall “rewrite” and more of the team “refactoring [the code] slowly” over a period of time.)

RJMetrics released the new version of the product to all its customers in July, but by then many had already been using some of the new features for months. RJMetrics uses “feature flags” to control which features a customer can see. That way, the company can roll out new features slowly and get feedback on them.

“We avoid a ‘flip the switch’ scenario because it’s risky,” Merrick said, talking about how the company releases new features.

Those feature flags also help developers know when the new features are ready for prime time, Monihan said. With the feature flag system, RJMetrics can see how often customers are using the new features and use that to determine when to release those features to everyone.

Below, find out more about how the RJMetrics dev team works.

###

Languages and frameworks: PHP, Javascript, Coffeescript, Clojure, Angular.js. While using PHP was a “legacy decision,” the team began using Clojure two years ago because they liked it and thought it was a better tool for what they were building, said Merrick. It was also good culturally, Merrick said, because the team got to “deepen” themselves by learning a new environment.

Developer tools: Git, Github, Vagrant, Amazon Web Services.

How much open source do they contribute? “We have some small open source libraries, but we’d like to do more,” Merrick said.

How they work: They start with a roadmap and break that into projects and teams that will work on those projects. Each team decides how to organize their workflow from there: it could be Github Issues, JIRA, Trello or even a bulletin board with index cards.

What they’re looking for in a developer: People who are smart and adaptable. They don’t screen for knowledge of a specific type of language or framework, Merrick said, because languages have converged so much that if you can write one, you can write or learn the other. Instead, RJMetrics asks developers to solve “abstract problems,” he said. (By the way, the company is hiring.)

-30-
Juliana Reyes

Juliana Reyes became Technical.ly's associate editor after reporting on the Philadelphia tech scene for four years. She's co-president of the Asian American Journalists Association Philadelphia chapter and a two-time Philadelphia News Award winner for "Community Reporting of the Year." The Bryn Mawr College grad lives in West Philly, likes her food spicy and wears jumpsuits often.

Advertisement

Sign-up for regular updates from Technical.ly