There are all sorts of situations that result in a company looking for a support team to maintain a Ruby on Rails application. We often hear from companies who had a freelancer, contractor, or single employee build an application for them, who have since moved on to other projects. Or a company has previously partnered with another agency that has shifted to other
Regardless of what situation resulted in your search for a new support team, you’re here now, and you need to find the best team to manage your application. What questions can you ask to make sure you’re partnering up with a team that you can trust?
We’ve put together some interview questions that any team experienced in support and maintenance of a Rails application should be able to answer. Here are some things to ask when considering a Rails support team.
What’s the longest they’ve maintained the same Ruby on Rails application?
If you’re in the market for a support team, you might be looking for someone to partner with for the long haul. It takes time and money to onboard a new development team – they have to learn about how your application is structured, get to know its quirks, and understand how it interacts with your business.
There are a lot of agencies that specialize in quick in-and-out fixes rather than long-term partnerships. We never hesitate to point potential clients their direction if they need short-term help, as that’s not the type of work we like to do.
If you’re looking for someone to maintain your app for a year or more, and a team’s longest partnership is a few months, you might want to ask further questions or continue your search.
At the time of this article (December 2019) our longest client partnership is over 12 years.
What service do they use to monitor application performance?
Development firms responsible for Ruby on Rails applications should rely on performance monitoring tools for your app. 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?
We’re longtime customers of New Relic for this purpose.
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. Is this a high priority for their dev team? Do they get alerted when performance metrics cross thresholds? What examples can they provide of application performance improvement?
How do they prioritize upgrades with other maintenance?
Version upgrades for Ruby and Rails are necessary parts of support and maintenance for Rails applications. But it can be difficult to prioritize them within the workflow of regular support and feature requests for a live application. Version upgrades cost time and money to perform, but they aren’t necessarily noticeable for your end-users to see results from.
However, they’re extremely important for the health of your app. Whenever a Rails application gets behind several major versions, it stops receiving security patches from the team that maintains Rails itself. That means if a security vulnerability is discovered on an outdated application, the responsibility for fixing it falls solely on the development team maintaining that app.
It’s a lot of avoidable responsibility – especially when personal or credit card data is involved in an application.
We plan ahead to schedule these upgrades with our clients when possible. When Rails is planning a new major version, they usually announce several months in advance when they plan to release the version, and what older versions are no longer supported. We then put this on our clients’ radars if it will be a major upgrade. This allows them to budget for the time needed to perform the upgrade. As with most types of maintenance, if you do a little at a time, it doesn’t have to be a huge project all at once. When possible, we’ll upgrade to the newer minor versions of Rails between doing major upgrades.
Can I speak with a few past/current partners who are similar to my project?
It’s always helpful to speak with a developer’s past or previous partners for a first-hand account of how they work and communicate. It’s even more helpful if they have a reference who is similar to you. This could mean a similar industry, type of application, or
Ideally, they’ll have a few people to direct you to without doing too much digging. If they have trouble identifying someone that they have worked with that will recommend them, you might have uncovered a red flag.
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.
We’ve recently been using Solano and Bitbucket Pipelines for continuous integration on client projects.
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.
We believe that when you hire a Ruby on Rails support team to handle your application, keeping up with automated testing should be part of their responsibility. This is a major quality check for your Rails app and important for your application’s longterm health.
Bringing in a new support team to handle your Rails application will never be perfect. There will be bumps in the road and uncertainties along the way. But asking these questions when you’re talking with potential partners will help you gauge how different teams work.
