David Heinemeier Hansson, Ruby on Rails Creator: Interview
Check out Evrone's interview with David Heinemeier Hansson, the creator of Ruby on Rails, co-founder and CTO of Basecamp.
Join the DZone community and get the full member experience.Join For Free
David Heinemeier Hansson is the creator of Ruby on Rails, co-founder and 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.
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 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, 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 and 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 shitty? Anything that is obvious for 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.
The only way to become a good programmer, where, by definition, I define good programmers as somebody who writes software with clarity, is to read a lot of software and write a lot of software.
-David Heinemeier Hansson, Ruby on Rails creator and co-founder at Basecamp
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, not once, and not even twice, launching the new versions of Basecamp. For sure, it’s beautiful to grow old with your customers. That has a lot of benefits, and, 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.
Evrone: And our signature 'time-travel' question! If you had an opportunity to travel back in time to where you started extracting Rails from Basecamp, what one technical advice would you give to your younger self?
David: I wouldn't want to have known a thing. Ignorance is bliss.
We’re thrilled to welcome David to speak at the RubyRussia conference in 2020. Our team here at Evrone is also looking forward to the continuing evolution of Basecamp, and, of course, Ruby on Rails. The more powerful the framework becomes, the better the solutions we're able to craft for our clients and partners. If you have an idea for a project and are interested in using Ruby on Rails, our developers are always happy to discuss the possibilities with you. No matter what stage you’re at in your project’s development, feel free to leave us your contact info, and we’ll be in touch soon to see how we can help you reach your goal.
Published at DZone with permission of Elizabeth Lvova. See the original article here.
Opinions expressed by DZone contributors are their own.