David Heinemeier Hansson

Creator of Ruby on Rails @ RailsConf Chicago 2014

Description
Transcript
  • Chat with DHH about nuance, where he stands with TDD today, increasing the bandwidth of conversations and his thoughts on how F/OSS software is used by for-profit corporations.

    This was the first of 30 interviews conducted with members of the Ruby and Rails community at RailsConf Chicago 2014. Other interviews with people you might know are Evan Phoenix, Aaron Patterson, Richard Schneeman, and many other less-well-known-but-you-should-get-to-know-them people. UGtastic exists to share and promote all people who are working to make tech community awesome - no matter how famous they are.

  • Mike: Hi it's Mike with UGtastic. I’m here at Rails Conf 2014, and I’m standing here with DHH, David Heinemeier Hansson. You might know him. He's written a few books, done a few... stuff. I think you might have something to do with the product that we're here for the conference about. But we're going to talk about his keynote he just gave about clarity and being a software writer. Well first of all I want to say thank you very much for taking the time to talk with me.

    DHH: Sure!

    Mike: So, your keynote, what was the gist of what you were trying to communicate?

    DHH: Sure! So, I think the identity of most programmers are coming from an angle that doesn't fit to the development of information technology very well anymore. And that angle is software engineering. I think there is a lot programmers who create information systems where engineering is actually not the primary thing that they do. What they do with they write. They’re software writers. They're trying to achieve a level clarity, figuring out first of all what are they building. It's not like a bridge where you just know… well it needs to go from there to there. And we have the structural bearing and so on and so forth. A lot of systems are very vaguely defined. Right? So figuring out what you want to build is very much like figuring out what you want to say.

    Mike: Right. It's more elastic than to just go from here to there.

    DHH: It is. And it’s more fuzzy… and it’s not as objective. It’s much a more subjective endeavor. And I find that writing is a much better metaphor than engineering. And within that, I find that one of the main ways that people are driving their development right now is TDD (test driven development) and I've just uh… I used to be a big fan. I used to be a big fan because it sounded like it made a lot of sense to me. What I found over the years is that the test first approach, driving your design through the test, actually doesn’t make that much sense to me. And I found that a lot of the software that I looked at and discussed with people, sorted through, that was created through the test first paradigm, wasn’t better. It was worse.

    Mike: And what’s interesting though is it seems like rails was very early on in the whole test driven development and putting it out there and even introducing it as a concept. But now 10 years later, you’re feeling like you’re backing away from that original…

    DHH: Yeah. So I think Rails was probably the first framework that just had test by default. We had a place to put the test. We generated them through this gap per default. And there is still a lot of good to that. It’s not that tests are bad. I think… I can’t imagine building a modern application today without tests. If you don’t have an automated tests, you’re really in the woods. But I don't find it as the primary objective my design discipline.

    Mike: It’s a little more nuanced than that.

    DHH: It’s a little more nuanced than that, and mostly it’s just test first worked for me for the tiny majority of the things that I do. But for the majority of the cases, test first, especially when focused on the unit, instead of the whole system, actually ends up creating more problems than it solves.

    Mike: Okay. But, like I was saying, it sounds like you developed the more nuanced approach. And it seems like some other interactions with people in the community is a little bit more dogmatic one way or the other. Are there people kind of taking Rich Hickey's stance of “Ah, test-driven development, that’s silly. And then there is the other side, the Bob Martin camp, which isClean Code", and even let a little shot at the dirty code there slide. But listening to your conversation in person versus observing conversation online, it sounds like some of that meaning, that nuance, gets lost sometimes.

    DHH: Sure. I mean anything on Twitter is void of nuance. You have 140 characters. The only thing you can put out is absolutes. And they can be influential in starting the discussion and driving it. You won’t get all the nuance. You have to go deeper than just a 140 characters of course.

    Mike: Has the ping-pong helped with that?

    DHH: I think the ping-pong helped me crystallize my thoughts on it a bit. The ping-pong basically, for people who don’t know, is people submitting a piece of code. I did that on Hacker News a few times. Then some guy set up a site for it, and we went over where this code could go. We agreed that the original piece of code was bad. And then people would ping-pong on it. Some people would then say, “Oh well the code was bad because of the pattern, or it wasn’t testable, or whatever.” And I would try to go in a different direction where, wherever I applied this ping-pong, it was about clarity. How could I make this code clearer, simpler, easier to understand, or conceptual overhead? All these things, right? And I find out, I ended up in a very different spot. That’s what partly helped me inform this, that we are going in a different direction. You end up somewhere else when you go through test first than when you go through clarity first. I don’t want to call it that because I certainly don’t want to have to hear anything like “clarity-driven marker”. It sounds ridiculous.

    Mike: Yeah. Well I talked to Dan North and it’s the same thing when they start with an idea and then it becomes dogma by other people who adopt it.

    DHH: Yes!

    Mike: You don’t want to have that rigid…

    DHH: I think that's what the… I had a quote by Kent Beck that’s incredibly reasonable, that talks about sort of confidence levels in your code. More so than just talking about… “Well, every piece of code needs to be written with a test failing first.” I think it's just not… I don’t know if it’s not… realistic. Because I’m sure it’s the real stuff for somebody. It’s certainly not realistic for me. It’s not the real for me and it doesn't arrive at something better. I tried! Very hard. Multiple times. And I didn't find that it took me to a good place.

    Mike: And the one thing I see with the ping-pong is at least it gives a concrete “A” and “B”…

    DHH: Yes.

    Mike: …That can be talked about and reasoned about…

    DHH: Yes. Before after code is… I'm really a big fan of that because it crystallizes a lot of arguments that are otherwise very fluffy. It’s very easy to talk about these things in the abstract. Talk about in the abstract. Because everybody agrees, yes we should have clear code. It’s not a controversial term. But when you apply it to an actual piece of code, then it quite quickly can become controversial.

    Mike: Okay, so you know I wanted to ask a few questions. Some people have contributed ideas for topics. One of those was about just your experience releasing Rails as a major project, and that it gets used by companies that make billions of dollars.

    DHH: Sure.

    Mike: But they don't always give back even a fraction of what they…

    DHH: Yeah…

    Mike: How have you dealt with it? I mean it doesn’t sound like you are doing too shabby but…

    DHH: Sure…

    Mike: But not billions of dollars shabby.

    DHH: Yes I know, and I don't need to. It doesn't bother me at all actually. There are a lot of people who do feel like… well… they're owed something because they contribute to open source. I think that’s an unfortunate perspective to have on what you are doing. If you’re doing it for external reasons and external rewards, that’s not why I’m doing it. I'm doing it for my own reward. A big part of my own reward is that I just enjoy it. I'm not doing it for somebody else to land me a payday out of it. And I enjoy sharing it. And a side effect of sharing it freely if people use it like they want to, like I wouldn’t want to use anything, is that some people can choose to use it to build great things that are of great value. And I don't see any of that value… and that’s ok. I think that’s where open source… I’m a big proponent of open source… but there's a side of open source that I’m not that enthusiastic about. GPL, to some extent, is that side of it. I'm not enthusiastic about roping people into… “You have to either donate code, or money, or whatever just because you used something. That doesn't appeal to me, especially on the code part. I don't want the code of somebody who doesn’t want to give it. Like, that's going to be my perspective. It’s probably not very good code. And so what. I don’t care if somebody extends it. If I need something in Rails that I don’t have already I’ll build it my damn self.

    Mike: Right. And you know, actually that since you brought up the GPL… that was going to cover in another question… but, I do want to ask about… so Rails is open source and many libraries that are used by it… well all of the libraries that are used by it, are also part of Rails or open source… omakase selected gems, but Rails itself, that’s a trademark. I didn't think about this until just now, is that there does seem to be a line between the codes out there and you can use it, but the brand itself? Has that helped keep Rails on the rails?

    DHH: I think it helps keep rails being this one thing. It is very easy to dilute it. In the early days we had a lot of people actually calling their frameworks in other languages, Rails. And that's not a great thing. Like, I make my Rails with a certain vision, with a certain approach to it, and I want people to be able to know what that is. I don't want people to pick something else up that says Rails. They think it's something that I made, and then it is some fucking PHP framework that I really wouldn't want to touch with a ten-foot pole, right? So I think trademarks are good in sort of removing confusion. So I mean… that’s what they’re there for, right? They’re there for… it’s just that like a certain company, or certain product, they can be that thing. Coca-Cola can sell their cola. And it’s called Coca-Cola. And somebody else can’t sell their cola as Coca-Cola because the consumer would get confused. And I think there is great value in that. I’m sure you go overboard and people do that all the time. Some of that is unfortunately part what trademark law is. That you have to sort of enforce it or otherwise you lose it.

    Mike: That’s tricky to keep that boundary from cutting people off.

    DHH: Yeah. For me, the whole thing about keeping Rails as a trademark is just for avoiding that confusion. I don't want them to be representing the official Rails, if it is not something that I believe in. Because that’s going to reflect poorly on me. So, that's the reason we have it. We haven't really used it for anything else. There’s incredibly little economic value being derived from it. Protecting what Rails is.

    Mike: Ok. And another question you know you talked about the GPL. What are you feelings about companies whose business practices you don't necessarily agree with, though, using your product? Using Rails?

    DHH: To me it’s like, I'm also paying my taxes. And some of those taxes go to pave roads. And some people who drive on those roads, I don’t agree with. So what?! It really doesn't matter. I can completely distinguish between the technical aspects about what somebody is doing, and then their otherwise business practices. So to me, there is absolutely no sort of conflict in calling out companies who I think have poor business practices, whether they are using Rails or not.

    Mike: But, how about when they come out and say, “Oh we’re a Rails shop.” And you're like I wish you didn't say that… you know?

    DHH: Yeah. I don’t. To me it’s like to me, it’s MIT, you can take it. You can do whatever you want with it. I'm not responsible for anybody who uses Rails, what they do with it, with the individual members of the Rails community. I don't want that police role. This is not a hierarchy in that sense. It's not like somebody who uses Rails is my employee and I have to be responsible for anything they say on behalf of Rails. Just because somebody uses Rails doesn’t mean that they’re expressing thoughts on behalf of me. That’s not how this is. That’s explicitly why this is MIT. Take and do whatever you want with it. No strings attached, right? Because then there's not that obligation for me to police everybody who uses it, how they use it, or whether they're good people, they're bad people, or whatever. It’s just not… it’s a separate thing and I don’t want that as being part of what goes into Rails. It’s enough, sort of, on my shoulders to run Rails as the vision of the framework, and so on. If I also had to be responsible for anybody who chooses to use it, and what they do… fuck that!

    Mike: Okay. And yet the last one is a little bit more of a fun question in relative to the theme of UGtastic, and that was during your keynote. You mentioned going as a child to see… or as a young man… young boy, to see The Gathering group back in Denmark. But your… just to go back in time to when you first were extracting Rails from Basecamp before, I get nervous I thought that I was going to say the wrong thing. But when you're first extracting it, you wanted to show it to people. You wanted to get people to look at it and check it out. And you were going to user-groups. When was the first time the user-group or conference presented Rails? What was the reception?

    DHH: Yeah. I think I actually first showed it off to some friends who were working at a couple different companies. And they were like… “Yeah yeah, that is sort of interesting.” I didn’t get a whole lot of feedback to it. Then I showed it off at Danish University. And, at the university's itself, I don’t know, maybe 30 people or 40 people, were like… “yeah.” People were interested. But it was like getting the video up. That really made people interested in it. Getting it up online. Just meeting with a local group of people didn't really do that much in the beginning. Where I found like-minded people was all over the Internet. I posted a video and someone was like, “Oh they wrote me in.” This is really interesting. I want to learn more about this. At that time I was also on the Ruby mailing list. I was participating a fair amount in that. Talking on there. IRC. So, for me, it was always about the virtual groups. Not so much about a meeting in person. Even though that's great too. I mean, that’s what we're doing here at RailsConf. 1500 people. It’s great to do that occasionally. But the bulk of the real work happens remotely. It happens from people just working for wherever they are. Because you look at the Rails core group and the Alumni group. They are from all over the place. They’re from all sorts of different countries, in different cities, and so forth. And, if I just had to run Rails just out of the programmers available in Copenhagen, no, of course it wouldn’t be as good. Having the whole world work on something, versus having one city, one tiny country work on something… it’s not the same thing.

    Mike: And I remember that video coming out because I was actually a Microsoft developer at the time. I didn't like it (working with Microsoft). At that point in my life in my career, the options were limited. I just remember seeing that going… “That’s cool! I want to work with that someday.” So yeah, I appreciate the creation and the work. And, it’s very nice. Um… now I gushed and I forgot what I was going to say. But, no, I again, just want to thank you again. I know you’re busy and you have to go.

    DHH: It was my pleasure! Absolutely! And thank you for putting this out there. I love talking about it.

    Mike: Thanks!

    DHH: Alright! Thanks everyone!