Keynote: Interview with David Heinemeier Hansson

Talks

David Heinemeier Hansson

#developer-experience-dx

Keynote: Interview with David Heinemeier Hansson

by David Heinemeier Hansson and Evan Phoenix

The keynote interview at RailsConf 2020 features a discussion between David Heinemeier Hansson (DHH) and Evan about the evolution of Ruby on Rails, his current work with Basecamp, and his perspectives on technology trends. DHH begins by reflecting on the impact of the global pandemic on his work and personal life, highlighting a shift in focus during the quarantine period. He addresses the initial plans to unveil a new product but instead emphasizes the challenges posed by the current environment.

Key Points Discussed:
- Product Development Philosophy: DHH talks about Basecamp's approach to building applications, emphasizing the importance of maintaining a 'majestic monolith' as the core architecture, leading to effective product development with minimal team size.
- Mobile Development: He discusses the shift in mobile usage statistics and reasons for focusing on crafting a full native email application, prioritizing performance and user experience.
- Consistency in Technology: DHH makes a case for why the fundamental practices of Rails have remained relevant. He draws comparisons between the early days of Ruby programming and the current landscape, noting minimal changes and expressing contentment with the programming model.
- Cyclical Nature of Technology Trends: Throughout the conversation, he references the pendulum swing in technology, mentioning past architecture debates, such as microservices versus monolithic applications, and how he believes that certain older methodologies are resurfacing in relevance today.
- Rails Open Source Evolution: He reflects on his changed role within the Rails project, noting that he now oversees the project more as a fan and user rather than as the primary coder. By fostering an inclusive environment for contributors, he emphasizes collective growth and evolution of the framework.
- Views on Static Typing and Formatting: DHH expresses strong opinions against strict formatting tools and static typing, arguing that they could compromise the expressive nature of Ruby, which allows for a myriad of programming expressions.

Conclusions: DHH suggests that the future of Rails and Basecamp is geared towards simplicity, cohesive design, and effective use of technology without overcomplicating structures. He encourages a return to principles that maximize developer productivity and joy in programming.

Overall, this conversation provides insight into the philosophy driving Ruby on Rails and how DHH's personal experiences influence his approach to technology, development, and team dynamics.

00:00:09.250 How are you hanging? I'm pretty good. No, better than I was two or three weeks ago, I’d say. I think just the exclamation that always happens has happened. Yeah, for me at least, to a large extent. I mean, the world is still messed up, and life is not back to normal, but I think we're in week five or week six of our time at home. My eight-year-old asked me yesterday what week it is. I said, "Honey, I don't know, I'd have to figure that out. You're lucky I know it’s Thursday." Almost like we’re in a new time calculation. It's like time started at zero with the quarantine.

00:00:44.769 We're now in the seventh week pretty much. All right, so we got a bunch of questions. I thought we could kind of wander around in the questions and just talk about various things. We can referee; I’m sure we'll make it through the whole topic list, and I figured we’d go for about 45 minutes or so. But first, perhaps I should just address my keynote a little bit. Our plan was to launch a brand new product the week before RailsConf.

00:01:16.420 So, we launched Hey.com the week before RailsConf, and I had a bunch of new tech in that app that I wanted to talk about. But then all this sort of happened. I went three weeks where I did nothing but rant on Twitter and try to pressure companies into doing the right things, and all sorts of other things, except program Ruby and make progress on the product. Therefore, I was unable to make progress on the things I wanted to talk about. In the end, I realized I didn't have the product ready to present, nor the technology wrapped up. I thought rather than doing this half-hearted thing where I can only tell you about it, I’d rather save that reveal for when we can actually show how we do the front-end differently.

00:01:50.590 Sure, that question got asked on Twitter like, "What’s going on with that thing?" So, we’ve got some adjacent questions we could get into. For instance, have you been doing anything different on mobile? We’ve heard you're building an email app, presuming it’s an email app for people who read email on their phones.

00:02:33.129 That might be a good start. Have you been working on that? I know that Basecamp has an app, and that’s been pretty static since you first came out with it. Any thoughts? Yeah, that’s a great question, and it ties directly to what I was going to talk about. Our philosophy at Basecamp when making apps is first of all about the majestic monolith that is at the center of not just the web app but all the apps. This majestic monolith is not just an API server.

00:03:10.149 For example, in our native iOS app, when you go to a message, that rendering comes straight from the majestic monolith. It goes straight through a controller, straight through an ARB view, and spits out HTML. Now, what has changed over the years, especially in Hey, is where the border lies. How much of the work comes from HTML versus how much is involved with a fully native application? We’ve increased the native components, but even a few years back, I wrote that 99% of Basecamp was just web-based, and only 1% was native. Now, it's possibly around 10% native while the remaining 90% is still part of the majestic monolith.

00:03:53.439 We've followed this same approach in Hey, but expanded upon it in a variety of ways. We skimp on native apps to a degree because we need to ensure the native experience is excellent right from the start. With email, for instance, about 70 or 80% of Basecamp usage still comes from desktop. Conversely, with email, it’s likely the other way around.

00:04:34.130 We might see 80% mobile usage compared to 20% on desktop. So, right from the start, we established that the mobile experience had to be great and do the full native functionality right off the bat. It’s interesting because we figured this out over time. Our native app wrappers are written in pure native code; we don’t utilize frameworks like Ionic or others for reaching native functionalities.

00:05:39.590 We have fully native teams working on iOS, using Swift and all the standard Apple components. They essentially incorporated web views everywhere, but it’s not just web views either; building web views forms the core of all this interaction. Since they’re fast and not continuously reloading, we do the same thing on Android, using Kotlin and the standard setup. Our teams are still tiny, though—two programmers on each side for Android and iOS respectively, with a designer per team. So, we keep teams small at Basecamp.

00:06:40.750 The philosophy behind our approach has remained constant: I want to write Ruby. Not only do I want to write Ruby, but I also want to write as much of the application in Ruby as possible. Our majestic monolith is not only an API server; it has HTML at its core, and we strive to do as much as we can to write applications in a vintage style. In terms of developer ergonomics, I like to think that the peak of the web's usability occurred around 2004. While some may see this as being stuck in one's ways, the current model of developing apps with full API distribution and React on the front is enormously complex.

00:07:43.430 The multitude of moving parts has soared, and many think this is what we have to deal with. However, we can still reap many benefits of this modern approach using traditional methods. Our approach to development keeps Ruby’s productivity alive.

00:08:34.240 My general philosophy is just to ensure the productivity of the process. Maintaining a manageable size for the design team is key, especially when operating with small groups. The architecture we utilize allows us to keep complexities at bay, ensuring that we do not need numerous design teams. At Basecamp, we have 56 people, where 15 are dedicated to support, indicating we have very small teams.

00:09:28.390 Each team comprises just two developers on Android and two on iOS, with one designer for each team. This allows us a streamlined approach to building designs, ultimately contributing to the efficiency of development. The core product team works under these constraints with an extraordinary level of cooperation, reflecting our desire for a simplified approach. We could build everything from scratch in a native setup with a large team, but that’s not our aim. Instead, we focus on remaining lean.

00:10:50.910 This way, we avoid the pitfalls of specialization. At Basecamp, we have this dynamic where developers and designers can interchange roles. All our designers not only draw but also write JavaScript and Ruby on Rails code. They can prototype features and bring them to life, making development incredibly fluid. You're able to ship features from conception to deployment seamlessly.

00:12:06.610 I think it’s interesting in how this avenue for development diverges from the norm in many organizations, where specialization has become rigid. This flexibility contributes to the job satisfaction of employees at Basecamp, allowing them to embrace the variety in responsibilities.

00:12:58.450 As for how we've evolved, Basecamp has been around for almost 20 years. Reflecting on this time, I realize that things have not changed that rapidly. The original Ruby and Rails code I wrote around 16-17 years ago doesn’t feel altogether different from how we develop today. The nostalgia hints that developer ergonomics from that time still hold as solid practices. There's a joy in the work, the aesthetics of programming, and the unique qualities of Ruby that haven’t altered much.

00:14:46.820 Of course, I've had weeks filled exclusively with programming Ruby, and I look forward to stepping away from the computer feeling accomplished. This joy combines with a love for aesthetics in programming, a connection to the work that remains unshaken over the years. That’s what keeps me engaged with Ruby and Rails.

00:15:56.460 I’ve been vocal about the changes in programming paradigms, and one thing that hasn’t changed is the importance of embracing Ruby’s expressiveness. The countless ways to express conditions or create logic is part of what makes Ruby beautiful. The programming experience is not just about the final product but also the subtle distinctions that allow creativity in coding.

00:18:47.860 I don’t want to see Ruby adopt a single way of doing things. I appreciate the diversity of expressions possible within Ruby, and losing that would mean losing a significant aspect of the language’s charm. We don't want Ruby to become narrowed or homogenized.

00:19:39.140 With that said, I deeply care for Ruby’s future, and I'm actively involved in what makes Ruby special. I hope that the core characteristics remain intact as the language evolves. The idea of inclusivity in this sense allows for continuous layering of features without sacrificing the fundamental joy of coding in Ruby.

00:21:42.000 As for Rails, our direction is towards maintaining simplicity and coherence in our approach while embracing relevant changes as they come, ensuring that we don’t lose sight of our original values. It's fun to experience the changes within the community, always excited to share and grow with the projects in play.

00:24:18.460 I encourage innovation and efforts to contribute, ensuring that the Rails community remains vibrant and welcoming. I’m constantly on the lookout for how we can take Ruby into the future.

00:25:45.240 I've been promoting innovations such as Hey at our company; it's the email service I've penned myself. I'm excited about what’s currently in the works, and pushing new offerings to showcase what we can do.

00:26:50.180 I also treasure the collaborations that shape our way forward, and I’m genuinely excited about the possibilities you’ll see in the coming months. The vibrant exchanges within the community speak to the goodness of the journey that we are on.

00:29:32.960 At Basecamp, I’m thrilled by the potential for overcoming limits, ensuring that our products remain cohesive, and harnessing all the elements we have. Yeah, I think we can transform how we build applications going forward and can’t wait to see what unfolds.

00:31:50.210 In summary, I look forward to where we’ll be as a community—it’s going to be an exciting time of growth and change.

00:32:47.320 Thank you for your time during this conversation and sharing your insights. I hope that you too are keeping well amid everything happening.

00:34:15.260 Here’s to more shared moments with our community. Your enthusiasm for Ruby, as always, is contagious.

00:36:08.040 As I said, my excitement about putting things into the world continues to motivate me. I really appreciate this opportunity to engage, and I hope for future interactions as we move along.

00:38:12.140 I can't wait to see how things shape out and have more discussions on our shared experiences.

00:40:05.950 Thank you once again for the conversation.

RailsConf 2020 CE