David Heinemeier Hansson is the creator of Ruby on Rails, co-founder & CTO of Basecamp, best-selling author, Le Mans class-winning race car driver, family man, frequent podcast guest, and inspirational conference speaker.
Ruby on Rails was created by David in 2003. From the day Evrone was founded, in 2008, we've been using the Rails open-source web framework daily. It has helped us write truly beautiful code for our projects thousands of times.
In addition to creating one of the most useful tools in software development, David has accomplished many other impressive feats, from writing the books "It Doesn't Have To Be Crazy At Work", "REWORK" and "REMOTE: Office Not Required", to racing in the FIA World Endurance Championship. In 2014, he came in first in his class in the 82nd running of The 24 Hours of Le Mans, the world's most prestigious sports car endurance race. He also won the WEC championship in the GTE-Am category that year.
In 2020, we invited David to speak at RubyRussia, Evrone’s 11th annual Moscow programming conference. Prior to the event, we got a chance to talk to David about the world of software development and his approach to writing phenomenal code.
The Interview
Evrone: Hey David, it's a pleasure to be speaking with you today. Let's start our interview. What is the best way for an average developer to decide whether they need to start with a "low JavaScript" approach and evolve their application later or use Angular, React or Vue from the start? What decision strategy would you recommend?
David: If you're building something that looks or tastes like a vanilla web app, like Basecamp, GitHub, Shopify, whatever, then I think minimal-JS is the way to go. It's not no JS, just minimal. If you're building something that's highly interactive, like a game, or a photo editing app, or anything that's more of the single-screen-tons-of-state variety, then looking into a full SPA makes sense.
Evrone: As codebase and team grow larger, what parts of the typical Rails application would you recommend to move into microservices? Given that a business wants a good code development organization, but rewriting the entire product from scratch is not an option.
David: It's a delusion that if you weren't writing software well enough to keep you from making a mess the first time around, that you'll be any better at it the second time around. You have to learn new habits, then apply them to where you live. Sarah Mei gave a great talk on this at RailsConf 2018. She was speaking about how the codebase wasn't something we build anymore. A codebase is a place where we live, and our goal is to make it livable for ourselves and for all the other people who live there. When we write code, our goal isn't to finish it and move on, our goal is to make it sustainable and livable for the team that inhabits it.
You can do all the rewrites you want, but if you don't change the little stuff that got you there in the first place, you'll just end up with a tangled network of microservices, just like you had a tangled network of class definitions in your monolith.
Your code is literally an interior space, occupied by people. The important part of the software is the system. It's the code and the people together and they are inseparable. The more we can think about software as an interconnected system of code and people, the closer we'll get to a breakthrough. The closer we'll be to a revolution, to a paradigm shift. And most importantly for us, perhaps, the closer we'll be to being able to build codebases that we're excited to work in.
-Sarah Mei (Founder at RailsBridge & LivableCode)
Evrone: Wow, that sounds mind-blowing, and we couldn’t agree more! What approach would you recommend while choosing between monkey-patching and other code composition patterns? What should we consider in order not to turn freedom patching into a mess of conflicting overrides?
David: Freedom patches are for creating general-purpose dialects of the language. Active Support is full of freedom-patches. It's not for creating app-specific changes.
Evrone: You have seen lots of Ruby code for sure. In your personal opinion, what makes code good or trash? Is there anything that is obvious to you at first glance?
David: If the code is poorly written, usually it smells before you even examine the logic. Indentation is off, styles are mixed, care is simply not shown. Beyond that, learning how to write great code is a life long pursuit. As I said in my RailsConf 2014 keynote, we're not software engineers, we’re software writers. “Writing” is a much more suitable metaphor for what we do most of the time than “engineering” is.
Writing is about clarity and presenting information in a clear-to-follow manner so that anybody can understand it.
There's no list of principles and practices that somebody can be taught and then they will automatically produce clear writing every time. If you want to be a good writer, it’s not enough just to memorize the dictionary.
Just knowing the words available to you, knowing the patterns of development is not going to make you a good developer. You have to develop an eye. You have to decide that the most important thing for your system is clarity. When you do decide that, you can start developing an eye.
I define good programmers as somebody who writes software with clarity, and the only way to become a good programmer is to read a lot of software and write a lot of software.
- David Heinemeier Hansson
Evrone: That’s absolutely true. You know, usually, it's hard for non-programmers that run companies to grasp the idea of "technical debt", "architecture" and rewriting the same app multiple times to get the better code. As both a programmer and a businessman, how would you recommend to sell these ideas to businessmen without a programming background?
David: I don't believe in rewriting an app for technical reasons, in almost any case. Sarah Mei's keynote illuminates why. But I do believe in rewriting when you want the application to do something fundamentally different. I spoke a lot about that in a talk at Business of Software Conference USA.
We've been rewriting the code for Basecamp quite a lot. For sure, it’s beautiful to grow old with your customers. That has a lot of benefits, but also a lot of disadvantages. You have to have some sort of renewal, because things stop moving and at one point you just have a very old customer base, a very shrinking new base of customers, and “a bucket”. Customers move on from their job and they leave your software.
The problem is, if you don’t pour in new water, eventually there won’t be any water left in the bucket. You have to make changes while things are good, which is the hardest possible time to make a change.
Nobody’s going to stay interested in working on the same exact implementation of their ideas forever. It just doesn’t work out like that. But, if you continue to renew it, if you continue to let your best ideas have an outlet, in their pure form, you can have a new green field and you can have your beautiful little house on it and everything is wonderful.
So please, rewrite your software.
- David Heinemeier Hansson