I’m a 48 year old developer and entrepreneur. I’ve developed professionally in C++, Java, Python, C#, Ruby, Go, and JavaScript. My current startup and my previous one were both built on Rails. Here’s why.
As an entrepreneur, my definition of “speed” is “the amount of time and money it takes to reach an objective”. Code execution speed sometimes matters, because I want happy users. But once the app is fast enough, being faster doesn’t help much. Fast means “fast enough to get the job done”.
Hiring for Rails
Once my company moves beyond the initial prototype, adding more developers is the primary way that we can accelerate the engineering team. Our ability to recruit and hire great developers is driven primarily by the talent pool and by the morale of our team. Talent pool is the first reason why your company can be extremely productive in Rails. The are a lot of developers out there who are skilled in it! And skilled developers who don’t have previous Rails (or Ruby) exposure, can pick it up quickly. The second factor in hiring a great team, morale, is driven in turn by two factors: company values (sometimes misnamed “culture”) and success. It’s often been noted that the company values are a reflection of values of the founding team. In my experience, this is true. “Success” is driven by the aforementioned “speed”. Success comes from quickly acquiring new users, making them happy with new features and bug fixes, supporting and them through problems. The more the team succeeds in doing this, the happier we are. And the happier we are, the easier it is for us to grow.
Coding for Rails
That covers the team aspect. Let’s switch gears and talk about the code base itself. I’m the CTO, so my world revolves primarily around the product code. I think it’s fair to say that successful startup code bases go through three phases:
- Prototype (5,000 lines)
- MVP (50,000 lines)
- Maturity (500,000 lines)
Note that in each phase, 90% of the code is new. That means you can rewrite the entirety of what you already have (in a new language if need be) and only take 10% longer. Less, actually, because you’ve already done it once before. Rewrites are fun and easy! Too bad it doesn’t often make more business sense to do them…
When we start a company, our goal is to get to that 50,000 line MVP. To get there, we need to meet business objectives like acquiring and satisfying users, and growing the engineering team.
The job of the code base is primarily to glue other frameworks, libraries and services together. We don’t have time to do anything else! Rails (and some non-Rails Ruby) is a great platform for building that glue. It doesn’t really have to do very much work. The work should be happening elsewhere; in the database, on the frontend (where compute power is free!), in native code like JSON libraries and database drivers.
So, back to speed. The job of the programming language and framework is to turn your team’s ideas into an MVP as fast as possible. Ben Halpern, founder of Dev.to, puts it perfectly in his blog post “I’m Ben and I am a Rails developer”:
I recall a blog post about a new company that had some
non-technical momentum which was completely derailed by
taking a simple idea and writing it in Go microservices.
I cannot remember where I found the post, but the story
was telling. They scratched their work and took a week
or two with Rails to make up for months of lost
productivity overthinking the problem.
So keep in mind: to a developer, speed means “performance on benchmarks”. The Ruby 3x3 benchmark and all the debate around it has once again brought out the Ruby critics who are reminding us all again how “slow” Rails is. To me, speed means productivity. Speed means telling my CEO and our investors that we are on track with the product milestones, and on-track with user adoption targets. Sometimes, there is legitimate performance showstopper in the app; a slow query, or a scaling issue with large data files. When that happens, a good engineer digs into the problem for a couple of days, solves it, and we move on. In Rails!
Key takeaways
In summary, as a startup CTO, my job is to coax the most “business speed” out of the dev organization as I can. Rails gives me speed, because:
- There is a lot of great talent available.
- Ruby is optimized for developer happiness, and happy teams are better teams.
- Rails is productive, and the second version of any Rails app is going to be faster and better than the first version of the same app written in any other language.
- The job of a framework, like Rails, is to glue other tools together. 80% of the program execution time should be spent outside of Rails (say, in the database). So making the web framework 2x faster only makes the app 10% faster. Optimize elsewhere.
That's why I build on Ruby on Rails.
- kevin
While you're here
We are conducting a survey: State of Software Architecture Quality. We are aiming for 300 responses, and once we meet our goal we will be donating $1,000 to Girls Who Code. Please contribute to our understanding of software architecture quality by filling out the survey! Of course, we will be summarizing and publishing the results once they are available.
If you don't want to fill out the survey, but you want to be notified when the results are available, you can fill out this form: https://forms.gle/u8CPS3GGD6A7WHsG7.
P.S.
I suppose I am trolling a bit by calling Rails the “world’s fastest web framework”. This is prompted by two things. (1) The kerfuffle over the Ruby 3x3 objective. (2) The degree to which developers will under-value their own time. As rhymes puts it:
the old saying “premature optimization is the root of all evil”
applies also to technological choices.
Top comments (23)
Do you ever reflect on your negative comments? Someone is taking an effort to make us understand that productivity is the kind of speed that devs should care about period.
I find it particularly interesting that the critics of rails leave off basecamp, hey, and many other big pieces of software that are powered by ruby and are doing just fine. Granted I don't know how large their user base is, but I do recall seeing DHH tweet about rails being able to at least power a $100m company(basecamp) and now an email service. Im guessing rails is plenty fast enough for those.
Thanks for a great article. I'm new to rails (a couple of months in) and I'm enjoying every minute of it.
The "machine" cost is no where near the "human cost". Unless you have a very specific case (to which you should optimize), there is no need to rewrite anything in X. Hiring additional people that knows X will eclipse whatever you are going to save by using fewer machines.
At the end of the day, the bigger bottlenecks are Databases and disk I/O.
Uhmm my understanding of the article is that you use Rails to get you started, but then you optimise.
I've taken that path myself, started with Rails and as demand grew we slowly spread into microservices across different languages. Twitter, Github, etc all did that.
Nobody is saying you stick with Rails forever. Some companies maybe don't even make it that far to reach performance issues that require badass infrastructures.
@ron - I think GitHub is ROR.
The GitHub site is still RoR but many of the services behind are not anymore. That's the sort of hybrid approach I'm taking about
Those are almost the same reasons that I use Django with Python, I will save the article to read again in the future, quite nice things to remember.
There's also just the bitter reality that most of us will never build a site that has the volume of traffic and users of Github, Airbnb, etc (who, incidentally do use Ruby). So the point about performance is probably not relevant for the majority or even almost all developers who build ruby apps in the first place.
What I see happening typically is that when the Ruby application does hit that magical hypergrowth period, developers/the company has a lot of pain, and then rewrite some of the application in Go. Not all of it, not half of it, not even 10% of it, just the parts that need to be super performant.
That doesn't negate all the benefits that using Ruby provides, imo.
The speed of coding/bug fixing depends on the skills, experience with the programming tools - of the coders /and their attachment to technical perfection from machine viewpoint/. Besides that note, I totally agree with you. Speed of development is more valuable than of execution.
When you achieve MVP you don’t get paid. You get to borrow more money (from VCs usually), which you can use to try and scale up your embryonic company. Meanwhile everyone is trying to kill you.
Where did 100 come from?
Benefits of Elixir: How Elixir helped Bleacher Report handle 8x more traffic:
Then again Phoenix/Elixir/Erlang are a special kind of beast.
That's 'Billion' with a 'B': Scaling to the Next Level at WhatsApp
Why We Chose Erlang over Java, Scala, Go, C
Which companies are using Erlang, and why?:
Robert Virding:
Second-Order Effects: Energy Hogs: Can World’s Huge Data Centers Be Made More Efficient?
Curious about this - how often is language the bottleneck (and the cost driver) vs. database and just a poorly optimized codebase (N+1 queries, bad SQL, etc.)? What have you measured?
I can programming C# and Ruby, I think I wouldn't consider C# jobs even a little bit higher paid. Using Rails is really peasure.