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.
Originally posted on Dev.to
Get AppMap