6 Questions to Ask a Ruby on Rails Company

Reading time: ~ 3 minutes

Are you looking for a Ruby on Rails development company to help with your project? Are you looking to build a Minimum Viable Product (MVP)? Or do you oversee an existing Ruby on Rails application that needs maintenance?

Do you have a spreadsheet with a few companies listed that you’re vetting? I encourage you to ask them the following questions before making a decision.

1. What’s the longest you’ve maintained the same Ruby on Rails application?

No, their own website does not count. It’s vital that you hire a company that has long-term experience maintaining production applications.

Development companies that deal with long-term support understand the benefits of following best practices. I’ve had many conversations with companies that hired a freelancer that was able to cheaply deliver an MVP but cut a lot of corners. This results in technical debt that you’re going to end up having to pay to repair in the future.

Find a team that works from the assumption that they will be accountable for your project in a few years. If they’re good at what they do, they’ll be more inclined to adhere to best practices.

(As of March 2016, our oldest client project has been in production for eight years)

2. What automated testing framework(s) do they prefer?

Ruby on Rails encourages automated unit, functional, and integration testing. There are some great tools at our disposal.

Did they respond with anything other than one of the following? If so, it’s possible that they’re trying to bullshit you.

Unit Testing with Test::Unit

RSpec

Cucumber

Capybara

(At Planet Argon, we’ve been big fans of RSpec.)

3. What service do they use for Continuous Integration?

If the team is mature, they will have Continuous Integration (CI) in their workflow. This is a form of automated quality assurance on your source code.

In a mature development cycle, the following should happen.

For each significant change that a developer makes to the source code, the CI server will attempt to run an automated test suite. If the tests no longer pass successfully, the team is notified that a possible bug was introduced.

“Carlos broke the build!”

We’ve had many projects come our way where the automated tests have been failing for months. In some cases, 2+ years…and the client doesn’t even know about the situation. Quite often, this was because nobody was responsible for keeping an eye on it.

4. What service do they use to monitor application performance?

Development firms responsible for Ruby on Rails applications rely on performance monitoring tools. You might ask them for more details, too. For example, ask them what metrics, specifically, do they keep a close eye on?

There’s a lot more to keeping an application well-oiled than fast page speed. They should be able to speak to performance with some experience. What areas of your project do they believe might have issues to keep an eye on?

The most common performance issues that we see in projects that we inherit are:

Slow database queries

Search indexes

A lack of caching

Missing database indexes

Slow AJAX requests

Slow page rendering on key pages

Ask them how often they check on these. Do they get alerted when performance metrics cross thresholds?

5. Have they contributed back to the open-source community?

A great selling point for Ruby on Rails is that it’s been one of the most innovative open source projects.

Every Ruby on Rails application benefits from the hard work and energy of those who helped shape it. In order for Ruby on Rails to continue to be innovative, it relies on developers to push it forward.

If the team that you hire does not contribute to the open source community, I would question their ethos.

6. What did they work with before Ruby on Rails? Why did they make the switch?

At Planet Argon, we were early adopters of Ruby on Rails. We were using it on client projects in early 2005. We didn’t switch to it because was the shiny new thing… we switched because it offered us a huge speed boost to our development workflow. Our team consists of developers that came from Java, Perl, PHP, ASP.NET, C#, Cold Fusion, and Python. There’s a large pool of experience on our team.

Everyone on our team made their own decision to switch to Ruby on Rails. We were lucky enough to find each other.

For me, it was the conventions that Ruby on Rails bundled into the framework that won me over. At the time, Ruby was such a breath of fresh air. Rarely do I miss my old PHP, Python, or Perl days.

While I could continue to share other questions, I wanted to keep this short and sweet for you.