A few days ago a prospective client asked “Why do you use Ruby on Rails?” and I told them a simple answer. Profitability and Productivity.
There is nothing else out there that can develop the majority of business web based software as cost effectively as Ruby on Rails.
This might be an unpopular position in an IT world that releases a new and shiny tool every other day, but I don’t care.
What I care about is the return for our customers, we could call this profitability. And the wellbeing of the team doing the project, which directly correlates to productivity. Ruby on Rails provides both productivity and profitability, in buckets. Large buckets. Buckets you need a crane to shift.
This post will also no doubt raise comments a million ways to Sunday about how this is obviously false, with endless examples where a certain technology clearly trumps Ruby on Rails. And many of these edge case examples will be true, and I will agree with them completely.
But the assertion still stands; nothing else out there can develop the majority of business web based software as cost effectively as Ruby on Rails.
Now, I realise that I am talking from an obviously biased position. Full disclosure time; I founded reinteractive. We develop business software that builds applications using Ruby on Rails. So I have a very clear, vested interest in saying that Rails is the best choice. So you can take this article with a grain (or a whole bag) of salt if you wish, but I intend to show you why I believe it to be true nonetheless.
First, am I qualified to make this assertion? Perhaps not.
But, over the past decade my company and I have created, developed, worked on, debugged, hosted and maintained approximately 200 software projects all running primarily Ruby on Rails.
Across these applications we have bumped into a bunch of other technologies, including Python, Angular (1 and 2), React, Ionic, various Apple tools, JQuery, Go, Phoenix, Elixir and plain old Javascript. We’ve worked on most of the major databases (both SQL and non SQL), as well as probably another dozen or so unmentioned and we’ve helped our clients deploy on many different hosting platforms. Additionally, I am in a position where I have been involved with almost all of these projects to some capacity from sales, oversight, customer management, and yes I’m happy to say, still coding!
I don’t believe there are a huge number of people that have touched, looked at or coded on as many applications as well as working with all of those customers ranging from one person startups to some of the largest Enterprise and Fortune 500 companies.
One of the big takeaways from this experience is that in the vast majority of cases, the client just does not care if the app is using the latest and greatest technology or if their app responds in 100ms or 5ms. What they care about is getting a working system in production generating the intended revenue or savings as rapidly as possible while maintaining a good level of quality and reliability. Ruby on Rails delivers this.
There is a lot of software being written in the world and most of this is some sort of business automation or workflow management software. It is the software that pays the bills, its original and continued development could be said to be the foundation of the entire IT industry. The sole reason the IT industry exists is to make business and organisations operate in a more efficient, and therefore, profitable manner. Everything in IT does this. From the server rooms to the physical computers, networks, operating systems, business programs (like word processors, spreadsheets and the text editor I am writing this post in) and workflow management systems like CRM and supply chain logistics. All of it exists to build a more efficient organisation and get some sort of competitive edge on the competition.
The other 1% of software systems are the unicorns of our industry. Held up as shining examples of what we somehow should aspire to with our business automation. Somehow, your system that handles the operation workflow for 10 people should be using the same tools and infrastructure technology that powers millions of transactions per second because that’s the way that Google, Facebook, AWS, Netflix and so on do it. This simply is a false idea. And in fact, a dangerous one that will probably cost you far more time and money and potentially bankrupt or seriously cripple the long term maintainability of your project.
You don’t want countless levels of microservice abstractions or code that’s hard to read because it’s built for “webscale” and not mere mortals. What you want is something that a new developer can start on at 9am and could contribute meaningful code before she goes off to have her lunch.
So what would be the ideal characteristics of a software platform to build the vast majority of business software?
From my experience, there are 8 attributes and they are:
- Fast to Build
- Easy to Maintain
- Well Supported
- Testing is Built In - Allowing Rapid Development
- Improvable Performance
- Opinionated
- Enjoyable to Use
- Cost effective The rest of this post will show how Rails averages the highest in my opinion across all 8 of these points.
Fast to Build
Ruby on Rails is widely recognised as one of the fastest ways to rapidly iterate on a functional design to build an application and get it launched. The beauty of Ruby on Rails is that it allows you to create an MVP (Minimum Viable Product) that you can launch and continue to modify as you develop further features. In other words, you don’t have to throw away the money spent on an MVP, you can just continue to improve it.
As you are dealing with a simple stack that was one of the first frameworks to popularise the Model View Controller architecture, you get a simple, database connected framework that you can make any tool you need, fast.
But the biggest reason Rails apps are fast to build is that so many decisions have been made for the developer. Ruby on Rails pioneered a very simple “everything has a place and a place for everything” approach to modern application frameworks. This results in a very rapid development cycle.
Easy to Maintain
The Fast to Build aspect leads straight onto being easy to maintain. When you are attempting to debug an application, it sure is useful to know exactly where to look to handle the problem you are hitting. Of course, this doesn’t happen all the time, and sometimes it takes you longer to find what you need. But the fact is, that because of the design philosophy of Ruby on Rails, more often than not, you DO find what you are after relatively quickly.
Having worked on several other development frameworks, I have found this predominately not the case in the wider world. Each project has it’s own project layout decisions made by the team, with different class and abstractions for different layers of the framework and application logic.
The value of this is hard to quantify, but just today, I had a new developer install a very non trivial multi tenanted Ruby on Rails application, on the other side of the world by just cloning the Github repo and following the readme, with no external support or questions able to be answered (I was asleep) and he got it done, and then fixed some things and wrote useful updates to the code to fix two issues I asked him to handle. All within the first few hours of ever seeing the app at all.
This is valuable. It gives new developers confidence that they can be productive and gives product owner (AKA the person that pays the bills) confidence that they can add resources as needed or replace lost resources rapidly.
Well Supported
Ruby on Rails is incredibly well supported in terms of developer resource and software library depth.
There are new versions coming out consistently with a very strong core team of developers pushing the boundaries of Rails. In 2016 the major version 5 of Rails was released expanding further on the core features available to get a new Rails application started with push notifications, faster page response times with Turbolinks and many more features. These include Yarn and Webpack among others that ensure the framework stays relevant with modern technologies and can move forward with new tools while still maintaining the convention over configuration approach.
2014 through to 2016, Ruby on Rails framework downloads (the first thing you need when creating a Rails application) has increased every year, 2014 with 12 million, 2015 with 15 million and 2016 with 24 million downloads, showing a growing community of users. The 3rd party libraries built for Ruby and Ruby on Rails are called “gems” and these are hosted by the community on https://rubygems.org/. At the time of this blog post, there were 130,746 gems published, over 111,371 open source contributors and over 13 billion downloads.
These gems handle pretty much anything you could think of, from integrating with social networks or allowing you to create invoices in your favourite accounting system to providing pre-built, community vetted and reviewed authentication and authorization tooling.
In fact, in 2016, there were about 44 new gems released EVERY DAY with more than 300 new versions of these gems released daily. On top of that the Ruby on Rails library was downloaded more than 24 million times with more than 92 million downloads overall and 463 thousand of them for the latest version.
That’s a lot of people interested in the project.
How does this help? Well, as a product owner, when you want a new thing built, you can leverage a massive amount of 3rd party open source tooling, cutting development time by orders of magnitude and get that new feature released, fast, instead of having to build that whole feature from scratch.
Does this result in less cost in building apps? Perhaps not, after all, in my experience, if we build a part of an application faster than expected, it makes more room for additional features to be developed. However, it does mean that you get more bang (features) per buck out of your budget and more time can be spent polishing the application at the end of the project to make it really sing.
Testing Built In - Allowing Rapid Development
This is an often overlooked aspect of software development, though with recent movements such as Test Driven Development and Behaviour Driven Development it has been given more of a spotlight.
Ruby on Rails has a comprehensive, easy to use, automated test system built into the framework structure.
Automated testing means that as developers build the features, they also write an automated test that runs the application in such a way to ensure that feature works now, and into the future.
For example, say you require all users to have both a given and family name specified. The developer would write a test that tries to create a user without a given and family name and the test would check to make sure the system does not allow that to happen. In the future, someone decides to alter this behaviour for another feature on the system, say for a newsletter signup where you only need an email. This might be months or years into the future, and the new developer has no idea about the requirement for given and family names when the system was built, however, when she makes the change, the automated test suite will fail, pointing out that given and family names are required fields.
At this point, the developer can talk with the stakeholders and either fix the newsletter signup feature so it also requires given and family names, or change the test because it turns out that the business has changed and the names are no longer important, or find another way to handle newsletter signups.
In any of those 3 options though, the result is the same. An automated test found an issue that if left un-confronted may have resulted in broken software being deployed to a production environment that could have prevented users from signing up correctly. This simple example highlights how automated testing works. But the real benefit comes when future developers are employed to update your software.
You could imagine that after months of developing, the system would have hundreds, if not thousands of automated tests, checking all the features developed. Every time the code is changed, the tests are run, and if all the tests are green the developer has a high confidence that their new code hasn’t broken anything critical.
This allows you to rapidly bring onboard new developers whenever needed. A new developer who gets your application source code and runs the tests and sees that there are a very significant number and that they all pass, instantly has high confidence that the application is well maintained and well written.
Further, they can get cracking immediately on writing some new feature, confident that if they do something wrong, the test suite will show them what broke and they’ll be able to rapidly resolve it ‚Äì increasing productivity.
The “best practices includes testing” approach in Ruby on Rails is a highly compelling reason alone to use the platform.
Improvable Performance
Ruby on Rails is built for high speed development first, and not so much high speed performance.
Witness Twitter that was built in Ruby on Rails, and after growing massively started having failures in being able to handle the traffic.
But Twitter was dealing with more than quarter of a million users and in a write up after the fact held Ruby on Rails blameless for their performance problems. There are very few business apps that would ever approach this scale.
Additionally, pretty much any major performance bottleneck in a Ruby on Rails application can be solved with some performance tuning. Modifying the database to return queries more quickly, keeping a copy of the results so they don’t have to be recalculated every time, improving the way the web pages are loaded to take advantage of Content Delivery Networks and many other approaches.
My blog post about Rescuing an Exploding Rails Application gives a good example of this. A client of ours had over 50,000 new users signing up per day and their Ruby on Rails application was having performance problems. After applying some of the performance tuning tools, we improved the application performance enough in a short time to handle the issue.
So, it’s a rare case where Ruby on Rails cannot handle the performance demands required of it, and also a very rare case where a business application hits those performance limits and when they do, they can be solved almost all the time quite simply. Also, in the exceptionally rare case that Ruby on Rails cannot handle the performance requirements directly, Ruby allows you to write and call highly performant C language functions directly, but in the decade of building Ruby on Rails applications, I have only seen this be required a handful of times. Not bad.
Enjoyable to Use
Ruby is the computer programming language that Ruby on Rails is built with. Ruby’s creator, Yukihiro Matsumoto said in an interview about The Philosophy of Ruby that the goal of Ruby is to make developers happy while writing it.
This might not seem like a big deal at first look, but the benefits are far reaching, in fact, so much so that I built my entire company around developing in Ruby and Ruby on Rails. Happy teams are productive teams. All of our developers get to program in a language that works with them, does things they expect, doesn’t surprise them (too often) and provides them with a framework that they can produce code that they are proud of. One of my team, who came to work for us after spending 2 years working on a Java application posted this in our chat room:
Working with tools that work with you and you enjoy working with makes a big difference to how well you develop.
If you are a developer and get up every morning loathing having to code another line in the language your application is built in, you might not stay at the top of your game for long.
Conversely, if the programming language rewards your developers for writing well structured code and does what they expect it to do, they will most likely be more content with it and generate less bugs while writing it. They will probably stick around longer because the job is more rewarding and enjoyable.
So the impact of a language like Ruby and a framework like Ruby on Rails has on increasing developer happiness is not to be discounted and actually should be a major reason for you to choose it.
Opinionated
Ruby on Rails is (just like this article!) quite opinionated. What do we mean by opinionated in the context of a web application development framework? Well, the software itself can’t have an opinion obviously, however the people that built it and maintain it certainly do.
This opinion encourages developers to write code in a certain way, to put parts of the code base in certain places and to use certain programming idioms in the way they produce their code.
How does this benefit the person paying for the application to be produced? It means you get a certain standard across all Ruby on Rails applications. A Ruby on Rails developer can walk into a brand new Rails application they have never seen before and usually be able to find what is wrong with it in a quick and efficient manner because they know where to look as all Rails applications are structured the same way.
This means the new developer can go from never seeing the code base, to up and running very quickly.
It also means that when a developer needs to build a new feature, they don’t have to think up a brand new decision about where to put that feature’s code in the application, instead, Ruby on Rails points out “That type of code belongs in this folder over here”. You could imagine (and I have seen) other development frameworks not having this level of structure would result in code scattered wherever the developer thought at the time it would fit. These sorts of applications are an absolute horror to work on as it’s very difficult to know what is where because there are no conventions.
I’m not saying that every Ruby on Rails application is perfectly structured with all the code in the right locations, but on average, from my experience, they are generally more consistent across different applications worked on by different developers. Again, this is a big plus for maintainability, which equates to future cost.
Cost Effective
Finally, this really is not a separate point, but the sum of the other seven prior points nicely wrapped up into something that makes clear business sense.
I won’t go through it all again because that’s what the prior post was all about, but building an app in Ruby on Rails is cost effective. It’s cost effective in time. It’s cost effective in resources. It’s cost effective in hosting. And it’s cost effective in maintenance.
Summary
So, Ruby on Rails provides you with a highly opinionated framework, that has testing built in, is easy to build and maintain, is widely supported throughout the world, has a massive pre built open source library for integration to third party tools, can be optimised as needed when needed and on top of that helps make a happy development team, and overall is very well suited to build the vast majority of business critical front and back office systems out there in the most cost effective way.
That’s some pretty compelling reasons to use Ruby on Rails for your next project!
