When Does It Make Sense to Hire a Ruby on Rails Developer (Full Time) to Support Your Product?

From Airbnb to Bloomberg to GitHub, many companies large and small are using Ruby on Rails to build powerful, scalable, and easily maintainable web applications, taking advantage of its cost-effective nature that provides fantastic quality and speed to market.

If your company relies on a Ruby on Rails application and has a full team to support the product, then you’ve got your bases covered. However, if you rely on a Ruby on Rails application, either built it in-house or through a contractor, but don’t have a full team you will be faced with the decision whether or not  to hire a full-time Ruby on Rails developer to support your product.

Ruby on Rails developers are in high demand and hiring on full time doesn't always make sense for a number of reasons besides cost. Before considering if it makes sense, there’s a few key factors that are important to keep in mind as you’re weighing the decision.

Access

When you need them do they have bandwidth to prioritize your work?

Hiring a full-time Ruby on Rails developer gives you clear access to the developer, in some cases even the ability to walk up to them in a physical office setting. When you decide to implement a new feature or spot a bug that needs urgent fixing, you have someone whose job is to report to you to  get the job done. 

24/7/365 coverage 

What is your crisis management plan?

Ruby on Rails products, like any application, will go down. It’s the nature of the technology ecosystem and even the Amazons of the world have downtime. To mitigate the damage from downtime, best practices include setting up automated alert systems and a method for notifying man power than can resolve the issue quickly. Finding Ruby on Rails developers who agree to be “on-call” 24 hours of the day, seven days a week, everyday of the year significantly narrows the talent pool. 

Replaceability 

If your Ruby on Rails developer is suddenly unexpectedly no longer available, how fast can you get a replacement up to speed?

What happens if the developer suddenly can’t show up to work? We like to consider the hit-by-the-bus scenario to ensure we understand the extent of recovery. Hiring takes time. Getting someone ramped up on a new code base also takes time. The combination is not trivial, in terms of time and money.    

Autonomy

Does your developer have the skills needed to deliver product?

A Ruby on Rails developer who is only able to backend developer can put you in a bind if you don’t have a broader team surrounding that developer. Products typically require visual design, user experience design, front end development, backend development, and systems management. Sometimes you can find a developer that is “full stack”, meaning they can do both backend and frontend. Maybe they also know enough design to be dangerous. These are the unicorns of the developer world and you need a special kind of bait to catch one. 

Pricing

Do you have enough ongoing work to support the budget required for a FTE?

It can be difficult to find the right developers in your area, especially if your budget is tight. Because Ruby on Rails is a relatively young web application framework, and it’s often used by venture-backed startups, there is significant supply pressure for Ruby on Rails developers - more demand than availability. Developers who know Ruby, the language in which Ruby on Rails is written, command the highest salary of all developers. If you have a large amount of work ahead of you, for feature builds and ongoing support, the budget requirements may justify the needs. 

In many cases, hiring a full-time Ruby on Rails developer makes sense. There are other options for supporting a Ruby on Rails application.

Other Options for Supporting a Ruby on Rails Application

Not every company can justify hiring a full-time Ruby on Rails developer, but every company can support its Ruby on Rails application by hiring a freelancer or agency. 

Option 1: Hire a Freelancer

Thanks to online marketplaces for freelance services and various online job boards, it has become easy to find talented freelance Ruby on Rails developers. 

The risks to working with freelancers come in many flavors. They will not work exclusively for you and so prioritizing your work over others may not always be welcomed, even in emergencies. Because of the high demand, it is very difficult to find freelancers who are interested in providing 24/7/365 coverage. Similar to hiring a full-time Ruby on Rails developer, freelancers are costly to replace and it is difficult to find the unicorns. Freelance developers typically charge an hourly rate, but it’s also possible to negotiate a fixed price, and because you don’t have to hire them for a full time workload, you can budget far less.   

Option 2: Hire an Agency 

By partnering with a software development agency, you get instant access to a talented team of Ruby on Rails developers–essentially outsourcing the risks encountered when you have a shallow depth in your team. 

Agencies manage the hiring and replacement of team members, and are adept at bringing in the right resources at the right time. Their promise is to be accessible and they also tend to have years of experience in re-balancing priorities in emergency situations. Some agencies can offer 24/7/365 support, offloading a critical business need to a partner with resources and experience in navigating unclear waters. Compared with freelancers, the average hourly rate of software development agencies tends to be higher, as they have management layers in place to ensure the quality of the work they deliver is consistent.

About Breakwater

Hiring a full-time Ruby on Rails developer has its pros as well as cons. Many companies look to freelancers or partnering with a software development agency to support their Ruby on Rails product. 

Breakwater is a software service company focused on supporting and expanding Ruby on Rails products for companies who need ongoing help maintaining them.

Our team of US-based Ruby on Rails experts has a longstanding track record of delivering business value and asset protection. 

Why did my software vendor fire me?

You found a great vendor. You came up with a great plan and executed on it effectively, maybe even staying on budget. You paid the agency hundreds of thousands of dollars and now you’ve got a high-end custom Ruby on Rails software application. It is just days away from launch and then you realize that there might be some work needed post-launch, or maybe there might always be some work needed here or there, but when you talk to the vendor they inform you that they don’t do maintenance work and–gasp–they aren’t “set up” for 24/7 support.

Surprisingly, your very trusted software development vendor doesn’t want to work with you any longer... sure it’s less money than the original project but isn’t this easy for them?

Why wouldn’t they see this as a win, they don’t have to invest in selling a new client, you’re just handing them a budget with a predictable relationship? On the surface it certainly seems they are the best partner for the job, given that they know the code base, they who wrote it after all, and they just spent the last six+ months working with you to create your new baby!

If this is your first time that you have had to experience this–sorry! It’s not unusual and in fact is the more common practice of many software development vendors. How come? 

Why aren’t vendors that build custom software also setup to help maintain and support that software? 

For one thing, what you may need is around the clock support but vendors may not have a single employee on their roster who wants to sign up for that. Everyone likes the fun, headline grabbing, innovative work–as long as it doesn’t impede on their personal or social lives. 

Here’s three other reasons your vendor may not be jumping to provide you support and maintenance.  

1. Employee retention

Vendors have a hard time keeping engineering talent. There is pressure from well-funded startups and companies that compete with those startups, effectively driving up demand and consequently salary levels for employees. Vendors are at an inherent disadvantage as they scale primarily based on headcount and billable hours, compared to a company with a software platform that can scale infinitely… bigger margins translate into less price sensitivity in recruiting and retaining the people to do the work. When an engineer at a vendor peers across the aisle they can jump ship to go work on “the client side” or for a startup and make 150% to 200%+ more than they were previously, plus potential of equity and an exit. To combat this problem vendors may look to create compelling and fulfilling cultures, “it’s like a family”, or more often than not work to present a stream of interesting work that helps keep an engineer engaged in the work, learning, advancing their skill set and resume, so they can later spread their wings. Meanwhile, support and maintenance projects tend to be the ugly stepchild of a vendor that no engineers want to work on and forcing them to do so risks increased churn and costs for hiring.

2. Resource Planning

Vendors that are effective at building new software platforms often require a diverse set of specialties to deliver the level of quality product you demand. This includes everyone from project management to user research and design, to visual design, front end development and backend development. Plus maybe copywriting, analytics, branding strategists and so forth. Keeping a collection of diverse specialists busy means finding client projects that fit a certain profile and can benefit from the skill set and service delivery. Most often this means big budget projects that span many months, like building a platform, product, or tool from scratch, that requires all the different departments to get involved. This kind of project can be put on a schedule, planned out, and balanced with other projects that have similar staffing needs. Teams can be formed around projects or entire brands, where each specialist is adding value, collaborating with other specialists, racking up billable hours and peeling off your project just as the next large one is starting. This doesn’t balance with the needs of support and maintenance. A support and maintenance request can often be both triaged and completed by a single individual. It may be significant hours out of that one person’s schedule, but doesn’t demand a full multi-disciplinary team, which then can throw staffing totally off-balance. When the support engineer gets tied up, delays cascade both upstream and downstream blocking other team members whose work is dependant on the engineer, keeping sales from booking new work on the schedule. While vendors tend to have extra bench time due to pockets of bandwidth, these utilization gaps are notoriously hard to predict and take advantage of to serve clients. Vendors are simply not set up to staff this kind of work.

3. New Business Portfolio

Vendors live and die by that work that they do. An innovative project that makes the cut for case studies and can be highlighted in their portfolio can lead to years of new clients and work. It helps attract talent. It can result in building out entirely new lines of business for a vendor. Innovative work requires taking risks and chasing the big sexy projects, sometimes losing money “investing in the future”, and certainly not small support and maintenance tasks. Even when the cumulative budget for a support and maintenance engagement is significant, there is little chance that the outcome might be award-winning or help a vendor make a name for themselves, get national press, or drive new leads. While it might be building your business and adding value to your customers, it’s not something that can be paraded around by the vendor as a way to win new work and talent. 

So. Your vendor may be “firing” you, but it could be one of those cases of “it’s not you, it’s me us”. They don’t have anything against you, it’s just not all vendors are set up to provide support and maintenance for your Ruby on Rails application. Breakwater is. Contact Us to find out how.

Examining and Optimizing Slow Queries with Explain Analyze in PostgreSQL

Rails removes much of the pain from coding database interactions, but this does not mean that developers can ignore the implications of unoptimized queries, which under normal circumstances manifest themselves as a sluggish experience for users. Slow page loads are one of the top reasons for users to give up on a web site, so it is important for developers to keep things speedy.

One of the tools available to us to view what is happening under the hood of the application is a PostgreSQL query called EXPLAIN ANALYZE. Other databases such as MySQL have similar tools available.

EXPLAIN is a command that allows us to view the query plan for a specific statement, and ANALYZE is the command that tells PostgreSQL to actually execute our query (as opposed to just coming up with estimates). Using the output of this command, we can isolate things like unindexed columns and expensive joins that could be causing performance headaches.

As a basic example, I’ve created a Rails app designed to manage Widgets. At the moment, the widgets table contains 1,000,000 records, each with a name and a price.

We’ll start by asking PostgreSQL to show us what happens when we look for a record with an ID of 56,777.

According to PostgreSQL, it took 0.071ms to plan the best way to run this query and only 0.039 to actually execute it. Because the id column is properly indexed, it can look up that specific record with very low overhead. However, let’s see what happens when we try to find a list of all widgets that cost between 60 and 65 dollars:

This query took significantly longer - almost a quarter second. While that may seem low, in a production environment it could be quite significant - particularly when coupled with the overhead of view rendering, etc. EXPLAIN is telling us that this uses a sequence scan, which means it needs to search the entire table row by row to find rows that match the given criteria. Indexing the column we are searching on (price) will result in speedier query execution, thereby speeding up our app. So, we can create the index like this:

Which results in a query execution like this:

Much better! Ensuring that your tables have the proper indices can ensure a snappy experience for your users. Little tweaks like this have very low overhead to implement, and depending on the size of your dataset can make a ton of difference.

Heroku-scaler: An open source tool for scaling Heroku web dynos on a schedule

Heroku is a great tool for hosting web applications. At Breakwater, we build web and mobile apps using tools like Ruby on Rails. Heroku is a fantastic place for hosting Ruby on Rails applications or the infrastructure (like APIs) for mobile apps. Heroku is fast and easy to deploy to and takes the stress and effort out of making sure the hosting platform is secure and redundant. It makes DevOps work easy, which allows software developers to focus on what they love most–building great applications.

One of the primary complaints with Heroku is that it can become expensive as the hosting horsepower needs increase. Of course, we can build a less expensive hosting infrastructure directly on a cloud hosting platform like Amazon Web Services (AWS), but building directly on top of AWS means that we are now in charge of security updates, backups, and other DevOps tasks. How can we have our cake and eat it too? 

Only use what you need

Heroku charges for most of its services by the minute. At Foraker Labs, we often have client products that don’t need peak resources all day long. For example, a typical custom business system is used primarily during the 9-5 normal workday. Ah hah! How about we only use the increased resources when we have those peak demands. There are services on Heroku that do this but I have found two problems:

1. They don’t seem to work very well

2. They cost money which defeats, to some degree, the benefits of scaling in the first place

Being a control freak

Naturally, as someone who likes to be in control and also likes to build things, I figured we could just build our own. Heroku has a great platform API and a convenient Ruby gem to easily access that API.

Enter Heroku Scaler

We have created the Heroku Scaler to give you control of scaling Heroku web dynos. Using the free Heroku Scheduler you can set up Rake tasks to scale your web dynos up and down at specific times. For example, you might:

• Scale your application to 3 performance dynos at 8am each day

• Scale your application down to 1 Standard-1X dyno at 6pm each day

This would allow your daytime users to enjoy increased performance but only pay for those resources during 10 hours of the day instead of all 24 hours.

How to use Heroku Scaler

The git repository has more detailed instructions for installing and using the Heroku Scaler but the basic idea is:

1. Add the heroku-scaler gem to your Rails project

2. Generate a Heroku API key

3. Set the Heroku configuration options

4. Install and configure the Heroku Scheduler

Want to contribute?

Breakwater loves open source. If you do too and want to make the Heroku Scaler better, please fork the git repository and submit a pull request.

A simple recipe for building a successful software Minimum Viable Product (MVP)

Building software is hard. There are libraries full of books detailing the failures and lessons learned. These days, the “lean” concept of a Minimum Viable Product (MVP) is all the rage in the software startup world but is still greatly misunderstood.

In the following paragraphs, I hope to help you understand how to succeed at building a software MVP based on our experience building custom web and mobile applications over the last 16 years.

In the beginning

In the “good ol’ days”, building software was war. Think of Napoleon marching into Russia during the cold winter of 1812. It took serious planning just to figure out how to feed 680,000 soldiers (which ultimately was a big problem for the Little Corporal). Building software was approached in a similar fashion. Product requirements documents were often several hundred pages of detailed specifications about what each screen would look like and what would happen on each button click or key press. Most software projects ended as well as Napoleon’s campaign in Russia.

Yesteryear’s waterfall model espoused careful plans, powerful tools, and lots of documentation. A quotation from Wikipedia says it best:

“The waterfall development model originates in the manufacturing and construction industries: highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development. ”

The idea was that every contingency must be planned for so that each part of the project could flow into the next. These concepts came naturally from building physical things but don’t make sense when working in something more malleable like software.

Failure is inevitable

Waterfall is still used extensively in government software projects, in large part because of the necessity for fixed-bid contracts. I’ll discuss why fixed-bid projects are bad for everyone in an upcoming post. 

The following from a great New Yorker article describes an all-too-typical outcome with waterfall software projects:

“Healthcare.gov involved fifty-five different contractors that each delivered a piece of the final system to C.M.S. for integration and testing. Whatever development processes those contractors used internally, the overall project was run according to waterfall principles. If the first testing of the complete system occurred in the last two weeks of September, then Healthcare.gov was only halfway through what Royce would have described as a complete waterfall development process. The experience for millions of Americans in the weeks since, predictably, has not been good. ”

More recent times

The Agile Manifesto helped to usher in ideas that have transformed our industry by pushing us all to focus on releasing software more frequently, in smaller batches, and with a greater acceptance of the inevitable changes. Hooray for these changes!

Enter the MVP

Entrepreneurs are faced with the challenge of trying to create something valuable with, typically, very limited resources. The MVP approach provides us hope by offering a path to reducing the costs associated with testing a product idea in the marketplace.

An MVP, per Wikipedia, is:

“…the product with the highest return on investment versus risk. It is the sweet spot between products without the required features that fail at sunrise and the products with too many features that cut return and increase risk. ”

But how can you, as a budding entrepreneur use the MVP approach to succeed with your product idea?

Some examples

There have been some smashing success stories powered by the MVP approach.

Twitter released a product with essentially a single feature–the ability to “tweet” a short message to the world. If Twitter had started with their full slate of advertising features, they may have missed the window of opportunity for the wildly successful social media channel and they would have spent far more money answering the most important initial question of whether folks would use the platform at all. 

Instagram released a product that only ran on iOS. It had no Android product and not even a serviceable web product. Like Twitter, they were able to test the marketplace while investing a much smaller amount of time and money to test their main hypothesis. 

Minimum versus viable

The brilliance of the MVP concept is that “minimum” is in tension with “viable”. 

This is really important. I’ll say it again.

Minimum is in tension with viable

Great! So we can take our long list of potential features and hold each up into the sunlight and ask

“do we need this feature for our product to live?”

and then we just build all the features to which we answer yes!

Not exactly…

There is a better way.

Once you have a clear, concise product vision and a reason to believe there is a market for your product, do the following:

1) Work on the most important thing first

What is the one, single thing that is the most important feature your product needs? You can only choose one. No cheating. This should be the feature that most makes your customer’s heart go a-flutter. Do that one first.

2) Maintain quality

Minimum does not mean crappy. The code must be well-written or your future progress will grind to a halt with bugs. The user experience must be intuitive or your confused users will become former users. The design must be compelling because good design engenders trust.

3) Rinse and repeat

Once you have that most important feature built, ask yourself

“Is my product viable?”

We are asking ourselves whether this product solves a real problem for some group of users, not whether it can survive in the marketplace. Twitter had no way to generate revenue but could answer the important question of whether anyone would use the product. It was a viable MVP.

If your product now solves a real problem and we can learn something from our users, SHIP IT!

If not, go back to step number one.

Bingo!

See how this approach addresses the tension between “minimum” and “viable”? We keep building the most important thing until we have something that is viable!

But…

There are some obvious questions that come out of this approach:

• How do I estimate the cost of my product so I can raise money?

• How do I decide which feature is most important?

• How does my team work on the most important feature (X) when X depends on feature Y?

These are great questions and I’ll address them here very soon