I’m rather late doing my writeup on Minnebar 2007. I guess the advantage of being so late is that I get to reference all the great write-ups that other people have done about Minnebar 2007. Let me start by highlighting that Ben Edwards, Luke Francl and Dan Grigsby did an absolutely amazing, fantastic supercalifragilistic job of putting together Minnebar. It was simply stunning guys – and you’ve set an incredible bar to try to exceed next year.

Here is the only thing that is hard about Minnebar. Both this year and last year it happened to coincide with one of the first, really nice weekends of spring. It’s hard being a Minnesotan and foregoing one of those great days to hang out inside. However, you are handsomely rewarded for the tradeoff. I didn’t see a lot of the people I had invited. You all missed out!

This year was simply great. The attendance was nearly triple last year. There were so many people that I knew in attendance that I ended up not going to that many sessions. In addition to the folks I knew, there were a lot of new faces to meet. I didn’t do any formal presenting this year, but I did get asked to lead the Q&A session with David Heinemeier Hansson, the creator of Ruby on Rails. It was a fun time, David is a really cool guy and I liked much of what he had to say. Tim Elliott got a recording of the session, with David’s permission, and I’m putting a copy of that here for archival purposes, with permission from Tim. (How Creative Commons of us all.)

I also want to give a big thanks to the guys from ip:House who provided the free WiFi service for the event. It was simply stunning in quality and capability, and not a single hitch the whole day. Great job guys!

I’m already looking forward to the next Minnedemo, and the next Minnebar in 2008!

Transcript

Jamie: Good afternoon everybody. Hope everybody had a good lunch. We filled up with some good pizza. I wanted to start the afternoon session with a discussion on the proverbial couch here. Maybe next time we can get a bigger couch. [laughter] But we were lucky enough to have David Hanson join us. And he’s going to take a moment to sit down and answer some questions on a variety of different topics. The format for today’s, this session is that I have a number of questions. I can certainly fill the whole time with questions, but I know that you all probably have some questions as well. So I’ll kind of guide things along and get things started, but then as you have questions, feel free to raise your hand and we’ll take whatever things you guys want to throw out as well. For those of you that don’t know David, David is the creator of the Ruby on Rails framework and is one of the major partners behind 37Signals, the maker of many great products that I think a lot of people in the room here use, and a resident of Chicago. So if you can join me in welcoming David. [applause] Wow. Can anybody see us? You think so? How’s this? This is better? I was joking earlier that somebody asked to give David a Windows laptop and we’ll call it Dignation. Alright. Soon we will– Soon we will be in position. I think the thing that Dan doesn’t recognize is that he’s significantly lighter than I am. [laughter] There may not be a couch after this. Alright, so just to get things started, David, can you take a moment just to share with us in your words what is Rails? 00:00

David: Sure. So Rails is a web application framework which is really a fancy word for a bunch of tools to make it easier to produce dynamic websites. And Rails then approached this from the angle of not only making– or not only helping people make dynamic websites but also making them happy in that progress. So we’ve really focused on the notion of just having happy programmers around doing the work that they love to do. So Rails doesn’t focus only on optimizing, say, speed or memory usage or any of the traditional computer science values, but just as much as on optimizing the happiness of the programmer working with the framework. So that would be the short spiel for it. 02:38

Jamie: Many people were curious what is the genesis of Rails? Where did it start? Where did it come from? How did this enter your head? 03:32

David: Sure. So Rails wasn’t really born as some great idea of wanting to conquer web application frameworks. It was extracted from me working on an application called Basecamp, which is one of the applications or products we have at 37sigmals, the company I work at. And I worked on this Basecamp application as the first thing I did in Ruby. And I came to Ruby from a background of PHP and Java, not being particularly fond of either, and just stumbled across Ruby and thought that’d be a great way to try this on a new web application that I was building for 37sigmals. And it turned out that even though I might not have loved working in either PHP or Java, there was a lot of things about both of those languages that I did enjoy, and I wanted to bring all that into Ruby. Because Ruby, when I came to it, was in some ways a little bit bare on the web application side of things. There definitely were some web application frameworks, but they didn’t quite fit what I was doing. So I pretty much embarked on just creating a web application framework one step at a time. Creating the pieces as I needed them, which meant basically working on Basecamp for a little bit, looking at what I did for Basecamp, trying to pull that out, trying to take the generic pieces and put them into a box that I could use for the next application we were going to do. So I started work on Basecamp in summer of 2003, which was also when I picked up on Ruby. And we released Basecamp in February of ‘04, and by that point, I had pretty much decided that these tools I was creating for Basecamp, I wanted to share them, because Ruby is open source. We’ve been using an open source stack. I’ve gotten so many great things out of using open source that it was pretty natural that when I was working on something new, that that would have to be open source too. So by the time of the release of Basecamp, I had decided that that’s what I wanted to do. But on a number of points, I didn’t want this to be like a lot of other open source projects that I’ve been using. I didn’t want it to be woefully under-documented. I wanted it to be fairly complete. So I didn’t want to release version 0.01. So I spent another six months or so cleaning things up, actually writing documentation, trying to put it together as a wholesome package, and then finally released it in, I believe, June of ‘04. 03:42

Jamie: Would Rails exist if you want to discover Ruby? 06:30

David: I actually tried to create Rails working in PHP. Let’s see. It didn’t go that well. Because the kind of things that I wanted to extract, the kind of things that I thought I saw patterns of usage, whenever I tried to extract that using PHP, I felt immense pushback from the language. It felt like the language didn’t want me to do these things. I took a hint and tried to use something else. It’s not that PHP is a bad language by any means. I worked at it for close to five years, and I got a lot of stuff done. So I definitely got a lot of stuff done, and people were getting stuff done in a similar way to what we’re getting done in PHP with Rails. But to me, it’s not just about getting things done. It’s not just about making the application work. It’s also about me enjoying that progress. And I wasn’t enjoying trying to extract Rails in PHP. It didn’t lead to what I perceived to be beautiful code. It didn’t lead to me feeling happy about what I’ve extracted. So that was a time for me to try something else that wouldn’t lead to those things. 06:36

Jamie: Feel free to raise your hand if you have a question. I’ll find you and bug out. So one of the things that you mentioned to yourself, you just said beautiful code. The Ruby community, particularly the Rails community, focus a lot on code aesthetics. You hear words like beautiful, elegant, much more than you do in other environments. And it’s really clear that there’s a culture to Rails and there’s a culture to Ruby that’s different than most other development environments. How do you think that first of all, why do you think that’s so important or is it so important? And how does that guide the continuing development of the environment? 08:00

David: So that’s one of the things that originally attracted me so much to Ruby. That Matt’s creative language had as his primary motivation for creating Ruby, that he wanted to see happy programmers. He wanted to make people happy about what they did. I thought that was just immensely inspiring. And so Matt wanted to make programmers at large happy about what they were doing. And I kind of picked up on that and said let’s try to do the same thing just for a more narrow scope of just web applications and web application builders. And part of what makes me happy about programming is to create aesthetically pleasing code. And that sounds in some ways superficial and it sounds like why is that important? The user doesn’t see the code. The user doesn’t feel any of this beauty and most normal sane people wouldn’t call a piece of code beautiful. But I…

08:44

Jamie: Present company excluded. 09:38

David: But I found it to be that creating beautiful code, creating code that I actually like working with is one of the most powerful motivational tools that I know of. There’s one thing that can get me to really dig in and get a lot of work done. It’s if I strike upon a path that’s creating aesthetically beautiful code and I’m then finding that when I’m inspired about something, when I’m happy about what I’m doing, I’m immensely productive. I really get a lot of stuff done really fast and it tends to be fairly good code if it’s aesthetically pleasing. So, I found that just to be my secret weapon for getting a ton of stuff done. More so than any of the individual pros and cons of language design per se. It’s, for me, the most important part of Ruby is how it makes me feel as a programmer. How I respond to it as a motivational tool. And the direct correlation I’m seeing between my personal motivation and my personal productivity. And that’s basically part of the thesis of why I think Rails is successful in some kind is other people finding that to be true too. If they’re enjoying the code that they’re working with, if they’re feeling that that’s producing something that they really like, they just tend to get more done. They tend to be more excited about what they’re working on. And that in itself leads to great productivity boosts. And maybe the part of what’s aesthetically pleasing or whether that leads to motivation is a little wishy-washy, but the correlation between motivation and productivity is not wishy-washy. It’s like proven from 20, 30 years of studies into programmer productivity. Steve McConnell, the author of Code Complete, among other books, has this great field. He’s summing up all these studies done for showing that motivation is the single most important factor in programmer productivity. That’s really what we honed in on and tried to optimize for. 09:40

Jamie: How did you come to programming yourself? 11:54

David: I came to programming through meeting programs. So I started doing actually game journalism back in the late 90s. And getting into that was kind of hard before the internet. There was one way and that was magazines. I didn’t particularly want to go that route, so I thought, “Hey, you can throw up a website and you can write whatever you want about games and maybe that’s a way to go forward.” So I found that to get a gaming website going, I needed some programming. So I got involved with just enough programming to throw up a content page with reviews of games and slowly just got into it through that way. 11:56

Jamie: Go ahead. 12:42

Audience: [ inaudible ] [ inaudible ] [ inaudible ] [ inaudible ] 12:44

Jamie: Just to highlight for those of you in the back, there’s a statement that beauty does imply efficiency in ongoing maintenance and support of code. That’s why it does have a long life cycle. Would you say that? 13:21

David: Oh, totally. And I think that one of the things that, in general, makes people most depressed about working on maintenance work is that they end up with, like, write-only code, like code that was written to optimize for various properties where none of those were aesthetically pleasing. And that’s kind of fine when you’re in the flow and you actually know what’s going on, but if you have to return to that code three months later and work on it again, those optimizations are not fresh in your memory, so you’re just stuck with the code that was actually produced, which is often not very aesthetically pleasing. And if you’re lucky, it might have documentation, but I always found code documentation to be kind of a prod. It’s kind of just a way around the fact that I’m producing ugly, unreadable code. Like, what about just making readable code from the get-go, something that people can actually understand from just reading the code? And then you don’t need to explain to them how this ugliness works. So that’s been one of the major driving forces, actually, and we pretty much have a policy at 37Signals of no code documentation. If your code needs documentation, you’re probably doing it wrong. Sometimes that’s not true. Sometimes you have to work around some library or some idiosyncrasy of the language or something else where you need to document that this is weird, this is something special, but that should be the exception. You should not assume that your code is ugly, unreadable, unmaintainable. If you assume those three things, it’s a pretty good guarantee that it’s going to be ugly, unreadable, and unmaintainable. So it’s just about changing that whole mindset of saying code should not be those things. Code can be readable, maintainable, and so on. And you get a lot of derivative attributes for free when you start focusing on aesthetics. So a 40-line method is probably not aesthetically pleasing. A method that goes in and out and in and out because it has a ton of control structures and three layers of nested ifs, that’s not going to look pretty. If you try to optimize that to look pretty, you usually end up with five methods instead of one. You end up with methods that are named what they do, surprisingly, or just a few lines of code, which doesn’t have nested control structures, doesn’t have all of these other desirable attributes that we kind of say, “Yeah, yeah, yeah, it’s good not to have nested control structures.” But if you don’t have aesthetics as a driving, important principle in the work that you do, it’s very easy to just brush that off. “Hey, it works.” Right now it does. 13:33

Jamie: Do you think that it’s hard that– many engineers I know don’t really have a sense of aesthetics. Is that something–I mean, do you see that? I won’t comment that David has really exceptional shoes on today. 16:14

David: I think that’s true to some extent, but it’s not really true, because a lot of geeks and engineers are fascinated by beautiful things outside of fashion. Mathematical proofs, things in nature, things that are just consistent, and a machine that has fewer moving parts. All of these things that are true to nature of engineers can very well be described as beautiful. If you try to relate it in those terms, it’s a lot easier. Aesthetics is not just about pretty things. I think that’s probably–code is never pretty. It’s not going to be pretty, but it can very well be aesthetically pleasing. Just as an implementation of some machine can be aesthetically pleasing. Like an engine, how an engine works. I find a lot of car engines to be very aesthetically pleasing. You wouldn’t point at it and say it’s pretty. There’s just more shades of words you can use to describe this. If you route around the notion of aesthetically pleasing, meaning fashion or pretty or these things, you find that there’s a lot of other areas where this is still true. It’s something that naturally appeals to engineers and programmers. 16:35

Jamie: Any questions? Just put your hand up. In your blog, you wrote about– you talk a little bit about some of the things coming up in Rails, but you highlight it specifically, and it’s interesting. The history of Rails comes out of Basecamp, and you highlight it specifically in the development of the new application from your company HiRise and some of the extensions to Rails as a result of that. Could you just comment on some of the things that you think are most exciting to you that we’ll see in future releases of Rails as a result of that? 17:54

David: Sure. For HiRise, which is the newest application from 37SQL that I’ve been working on for too long, I’m working right now on the API, so the way to talk to this web application through other means than a browser. Make some program that can talk to HiRise. Just as quick, HiRise is like a shared contact manager where you can share contacts with the rest of your company, what you’re talking to them about, and what you need to do next. It’s kind of like Salesforce but fun, sort of. Right. In some ways, it does kind of relate to the CRM-ish kind of thing, but without all the sales pipelining and so on. Just focused on people, what you did with them, and what you need to do with them next. For that work, I’ve been working on an API, and I had the intention of working on an API from the get-go. That’s really what kick-started my interest in the whole idea of REST. So using the web and the techniques native to the web to produce an API to run programs again. For a long time now, that’s probably been the major overarching theme of new, exciting things in Rails. The whole push for getting things to be natively REST-form. Part of that is something called Active Resource, which is basically– Active Record is the database mapping layer in Rails, which basically makes it such that you can talk to a database in Ruby, and it’s fairly pleasant to do so. Active Resource is basically the same thing, but for web API. So you treat a website like a database, and you interact with it that way. I’ve been just recently doing a lot of work with Active Resource, with making Rails easy to produce XML that Active Resource can easily digest. Through that whole process, we came up with a number of interesting points that has had a pretty big impact on how a lot of modern Rails applications are produced. A side note to that is it’s kind of interesting that REST has been out now for 2.5 years, a little bit more than that, and even in that short period of time, we have the notion of “modern” and “old.” But anyway, the modern approach to doing web applications in Rails is by and large this RESTful approach. We’ve been building a bunch of conventions on top of that that makes the controller parts of these things look very much the same across everything, making it just incredibly easy to think of your web application as more than HTML producer. For Highrise, for example, we’re dealing with contact data. Contact data often wants to come in a number of different formats than HTML, like CSV files. Somebody has an Excel spreadsheet with everybody for this conference that they want to get into Highrise. How do you work on that? You need to make your application understand CSV. And Vcards, like the standard for moving contact data between Outlook and AdWords Book on OS X, those kind of formats are something that we want the web applications to natively produce. And we don’t want it to be a hack-off. We don’t want it to be an action called “contact to CSV.” We want it to be part of the natural flow of the application and be just as valid as HTML. So this whole notion of perceiving your web application as basically multi-view. HTML is still, by and large, the primary format, but there’s a ton of other formats out there who can take advantage of exactly the same infrastructure set up. There doesn’t need to be exceptions. And when it’s not exceptions, and it does take advantage of the setup you already built for HTML, you almost get it for kind of free. And that’s the notion we’ve had with having HiRise produce XML, for example. A lot of the actions we have will just have, say, “person.toXML,” as that’s part of its–one of its return options that can return to XML. And I think that that’s just been really powerful as a change of mindset of what web applications are, how hard is it to accept and produce other formats, and what does APIs mean to this whole thing. So my hope is that this thing spreads more, and people just start natively thinking of their applications as multi-views from day one and not as APIs or these weird hack-on things we need to do because somebody’s requesting it down the road. And once you get that, we can start treating more web applications as databases in the sort that– I can work with HiRise for Basecamp and other applications we have just by instantiating an active resource object, and I don’t need to build all this stuff from scratch. 18:26

Jamie: It’s interesting because much of what you’re talking about sounds to me similar to when you hear Tim Berners-Lee talk about semantic web. And so is this kind of allowing us to drive Rails applications to become more part of future semantic web? 23:44

David: First of all, I’ve got to say that Tim Berners-Lee is a wonderful man, but I don’t have a lot of hope or faith in semantic web. I don’t have a lot of hope or faith in widespread adoption of perfect and marked-up data. I just don’t think it’s going to happen. The same reason that people go all the time on the desktop. If only people would add metadata to their PDFs, if they only would fill in the greater fields, what this was about, the description, and so on, people don’t. And they’re never going to. And we might as well just realize that. And I think that’s why Google is so fantastic, why Google works. And I think that’s the way forward, just recognizing human behavior and saying, “Okay, I’m not going to change how humans work. I just have to accept that for a fact. They’re not going to do the pre-filing.” That’s a big part of why tags became so big. Nobody wanted to set up a huge, hierarchical category structure up front and then file their little things into them. That’s just not how most people work. Most people are just not that organized. So tags allowed people to, after the fact, say, “Oh, by the way, this is a customer. This is a VIP. These things I can use to describe it for. I don’t need to have all the categorizations to be perfect up front.” And I think in some ways the semantic web, to me, I have a, I’ve got to say a disclaimer, a limited understanding, and even in some ways interest in the semantic web. So I might be wrong on it, but it seems to me that it requires too much structure too soon. And I don’t see people buying into that. 24:02

Jamie: I may want to throw a question out, and I’ll repeat it. 25:50

Audience: From your perspective, if it has, how has Rails impacted the evolution of the Ruby language? 25:54

Jamie: So the question was, how has Rails impacted the development of Ruby? 26:01

David: In some ways, I shouldn’t say surprising, that’s assuming, but very little. Like, the version of Ruby that I started using two and a half years ago, pretty much the version of Ruby we use today. Ruby doesn’t move that fast. And in some ways that’s great, because Ruby doesn’t have to use that fast, move that fast, because we can extend Ruby. So we are not settled with whatever Ruby is shipped with. In a lot of ways, Rails is a special version of Ruby. We have something called Active Support, which is basically all our ideas of what Ruby should be able to do more for this particular niche. We put it into a box, and we wrapped it around Ruby in such a way that when I start up a vanilla IRB, I kind of don’t understand this vanilla Ruby syntax. Because it doesn’t have all these things that I’m used to having. It doesn’t need to, it’s great. I have no rush for a new Ruby. I know a lot of people have this notion that only when Ruby 2 comes out and we get native threads and magic performance, things will be wonderful. Okay, I don’t really care. First of all, I don’t need a much faster Ruby. It’d be nice to have. It’d be nice to have an ice cream right now. I’m not going to die if I don’t get one. And I mean, that’s kind of how I feel. It’d just be nice. Free performance. Who would say no to that? You don’t need it. I don’t need it, and you probably don’t. I’ve got into trouble of saying that people don’t need performance, but I’ll say it anyway. Most people just don’t need a faster Ruby. They think they do. They think they’re going to be the next Amazon or MySpace or Twitter. Dreams are important, even– [laughter] Every kid on the block thinks he’s got to play in the NBA. Sorry, dude. Reality sets in, and ten people start doing that a year. And one startup out of hundreds or thousands will ever get that problem where they actually have to start worrying about these things. But that’s a hard sell. And I found that to be true, that everybody wants to think that they’re special, and who can blame them, even if they’re not? In that aspect of applications, I’m sure you’re all very special people. [laughter] So in some ways, we’re, I think, selling too much reality for some people. And it’s hard selling reality. What was the question? [laughter] 26:06

Jamie: I think we answered it. Ben. 28:45

David: Yeah, sure. Two questions. First, is there any gems or plugins that I use in my work that’s not yet in Rails? In some ways, Rails is my plugin. So I’m kind of self-serving in the fact that if I need something, it pretty often goes straight into Rails. I do have a number of plugins, though, for things that are not quite baked yet. That’s HTTP authentication, for example. I use a plugin for that. I use a plugin for OpenID. I use a plugin for… let’s see. I have a few other plugins. Nothing major. I tend to think of plugins as… they’re best when they’re tiny. I have a plugin that’s three lines of code, and I love it. That’s the kind of size I want to get for my plugins. I don’t want to get these huge honking beasts of plugins. So I tend to not use that many plugins. And if what I really… I’m a little bit ambivalent on the whole plugin thing. It’s great that we have this architecture so that people can extend Rails without actually bothering us about it. But at the same time, it kind of creates this atmosphere that, as part of this question, like, what are the secret plugins? What are those magic plugins that makes everything great? They’re just not there. There are not these special magic plugins, and you don’t have to use plugins. A lot of applications would do very fine if they had zero plugins. So I mostly just want to combat the whole notion that you need plugins. Sometimes they’re nice to have, but very often if you feel like you need plugins because something is hard, or you think something is hard, authentication is the bane of my existence. Just the number one plugin people have started asking about from day one, even though they hardly touch Rails at all, like, how do I get an authentication plugin? How do I get the user setup and ACL and blah, blah, blah? I re-implement that stuff every time from scratch. It’s really not a big deal. The problem with plugins are that they keep people in the illusion that it’s a big deal. Because they add this magic black box that they think does magic voodoo tricks, and really it doesn’t. Like, it’s a few lines of code. So, that was plugins. Gems? I really don’t like dependencies. That kind of means that for the vast majority of gems out there, I would prefer if they were part of the application. So, a few gems like Rake, system-wide tool that everybody will use all the time, like the MySQL C database connection, Rake, Capistrano, those kind of tools are great as gems. Stuff like Redcloth, for example. Redcloth is an implementation in Ruby of text style, which is a text formatting thing. I think it’s a bad fit for a gem. Because once you start relying on too many of these dependencies, shit just always breaks. You never have to plug the gem in the right version, or you rely on it, then you upload it to the server and it breaks. I’m not a big fan of dependencies. So, I try to shove everything I can into the application box. And I don’t mind the duplication. I think some of the things that really turned me off this stuff was Debian. So, Ruby on Debian comes, at least it used to, in 43 distinct packages. They took Ruby, not a huge language, and chopped it up into 43 pieces to make sure that there would never be any duplication, that you never had more than exactly what you needed. Who cares? Ruby is 5 megabytes of space. People who need to worry about getting 3.7 megabytes Ruby distribution rather than 5 megabytes of distribution, not the majority. Most people are fine just having a 5 megabyte Ruby distribution. That’s the same as everybody else has. And we’ve just had so many problems with that. Oh, I forgot to install the 41st package. Got it, now my application doesn’t work. I brought this ship too much into the– I’m trying to snap as much into– That’s also why Rails ships with a good number of other frameworks. We could have added probably at least 10 more dependencies on things that I– This is 75 lines of Ruby code. I’m not going to add a dependency to get that in. I’m just going to shove it right in there and kindly ask if I can bungle it under an MIT license. [laughter] Actually, we did get permission after the fact for all the things we’ve bunged. [laughter] Question number two was– 29:02

Jamie: It was the R spec. - Oh, yeah. 34:03

David: So there’s–TDD or test-driven development has always been a big thing in the Rails camp. And I’ve been a big proponent of not test-first and test-along development. I don’t necessarily–I’m not religious about the test-first thing. And I actually find that a lot of times test-first doesn’t work for me. I kind of need to work on the API sometimes a few times before I have to test. I don’t know what my result is actually going to look like before I start working on it. And now there’s this BDD, behavior-driven development, which is basically like test-first but calling your things something else. Which is–that’s not to be discounted. Sometimes the names of things matter tremendously. And I think that’s actually the most important skill a programmer can have is being good about picking names. Names for variables, names for classes, names for methods. All of these things are hugely important, so I don’t want to discount that. I’m just finding in the BDD case that I took one thing away, which was saying–use the word “should.” If you use the word “should” in your test case, like “overdue subscription should not process payment,” that very much frames this one test case about one thing, which is much better than “test overdue subscription.” There could be a lot of things about the overdue subscription that you could want to test, and you often end up with a test case that has, like, five different assertions that are not really that related. So I took that away, and I just shoved it into the test setup we have now, and I’m finding that that’s good enough for me. I totally don’t want to discount that other people need more stuff and their assertions should say “should” too. It’s just not a big deal for me. 34:06

Audience: David, you moved here from Illinois and moved to Chicago to be part of 37Signals. You’ve been working with 37Signals for a while. Do you have any thoughts about doing cloud projects or actually joining 37Signals, and how that experience can be of value to you as a small company? Do you have any thoughts about that? 36:03

David: Sure. 36:25

Jamie: The question was just how did you get connected with 37Signals, and a little reflection on how that’s happened. 36:29

David: So I started working with 37– Actually, the funny thing is, 37Signals was my first paid programming job back in 2001, 2002. I started working for Jason, which is my partner at 37Signals now, on an application called SingleFile, which is manager, book collection, online, kind of inventory database application. We did PHP back then. Since then, I worked with the company for about 3 1/2 years or so, during which time I was in school. I just worked as a contractor. 37Signals back then was doing design work for clients, and they would often pitch a design project, and I would do the programming side of things. So that worked out great while I was in school. And then once I was done with that, we were getting started with Basecamp, and I was done with school, and I had a decision to want to go for a master’s degree or start my own company, or whatever I wanted to do. And one thing I knew was if I was going to work at a company, I was going to work in some essence for myself. There was not going to be– At that time in my life, or still, at that time in my life two years ago, it was– I could sustain a lot of risk. So if 37Signals didn’t work out, fine. I didn’t get paid that much in the beginning. There wasn’t that much, and that’s how it is when you’re equity-based. You trade up front– You get risk and up front not much pay or something. Anyway, that worked out fine at the time, so the choice was really simple. Either I was going to be a partner at 37Signals, or I was not going to be with 37Signals. So luckily Jason thought, “Hey, I’ll be a part of the company rather than go somewhere else.” 36:36

Jamie: - A question on that, just coming into what 37Signals has been doing. Any hint on what’s going to be next from 37Signals? 38:41

David: - Sure. So we just launched FireEyes about a month ago, and I think going forward we have now five applications, and we’re going to make those work better. And we’re going to do more applications. So there’s no real major revelation or revolution there. We’re just going to continue to work on applications that we feel we need for our own problems, try to solve them the best we can, and improve the stuff we have already. We have no big plans to take over the world in some areas and niches that we don’t know a lot about or don’t care about. So we’re going to stay within the space of productivity and collaboration and tools to run the business that we run. That’s how we came up with FireEyes, was that we started needing, keeping track of the people we were talking with and what we had to do next and what we said to them. And that’s been the road pretty much in all the applications we’ve done, something we need for ourselves. And I think that’s just the easiest way to get a great application. Find a problem that you find annoying and valuable, something that you would pay for yourself if somebody else did it, and then start working on it. I think that that’s a very good driver. You can certainly do good and great applications working on behalf of somebody else, trying to get into their mind and figure out what their problems are. But that problem is not twice as hard. It’s ten times as hard. And I really don’t like hard work. [laughter] 38:52

Jamie: Does 37signals have– I mean, do you have– I would assume you have specific designers versus engineers. What’s the ratio? I’m just curious. 40:31

David: First of all, we don’t have any engineers. I hate the word “engineers.” Engineers are people who build bridges so they don’t fall down. They’ll get a piece of Ruby code and think it’s beautiful. So we have developers and programmers, and we actually have a fair amount of bleed-over. We have a good number of developers who have some sense of design, and we have designers who have developed some sense of programming flair. So we have currently, what, four developers, myself included, three designers and a systems administrator and a contract-based person to help out with customer support that just started recently. So that’s pretty much the supply. So we’re a little front-loaded on developers right now. It used to be more the other way around. I used to be the only developer, and now I’m one of three other designers. 40:40

Audience: What has your experience been working for a startup in a city that’s not really known for the high-security? 41:46

Jamie: The question was, what has your experience been working in a startup in Chicago, which is not necessarily known as a technology hub? 41:53

David: First of all, 30 Seconds Eagles is not a startup. We’ve been around since ‘99. We actually make money selling products that people want. I think that pretty much rules out 80% of startups. [laughter] So I kind of– a startup is something that doesn’t apply to us. We don’t work out of a garage. We don’t have VC funding. And we take it pretty easy in the fact of just working on stuff that’s profitable. So to me, we’re just a company. I think that term somehow got lost along the way in technology, that either you’re a startup or you’re this huge, massive corporation. We’re just a company. But being in Chicago, I think it’s wonderful. I think the times I’ve been in San Francisco, and especially lately in the West Coast in general, is how do people get anything done? [laughter] I don’t understand how, like, between all the parties and shit going on, it’s got to be kind of hard getting stuff done. And that’s what I like about Chicago. There’s not a tech scene that you kind of have to be part of and these things that you have to participate in. And along with that comes a mindset of actually just getting shit done. And I think that’s very helpful for us. That’s very helpful when you’re eight people and not looking to hire another 24 next month. Like, you actually need people to just get work done. So I think it’s led us to be way more… restrained in how we spend resources. We don’t hire a ton of people. We don’t think we need to hire a ton of people. We don’t throw elaborate launch parties and that kind of stuff. And I like that. It’s in some ways separating more that there’s… I’d like to do other stuff too. Like, not just be in this echo chamber of, like, tech startups. 42:00

Jamie: I’m curious. You’ve been writing a lot on your site about OpenID, and it seems like you’re pretty excited about it. What are your thoughts on OpenID, and do you think it’s going to make it? 44:13

David: Sure. So OpenID is basically a centralized, single sign-on with extra stuff. So basically, I’ve had the problem with other applications that I might have or be involved with four different base camps, and I have different passwords for all of them, and I can’t remember any of them. And OpenID just gives you basically one log-in to all your applications. And I find that to be pretty cool, pretty much. Or maybe in some aspects, because of all the work I don’t have to do. We have a lot of customers who keep clamoring, “When do you add single sign-on to all the third-sem sequence apps?” And, “Hey, somebody else went ahead and did it for me.” I love that kind of work. So OpenID, in our minds, has replaced the notion that everybody needs to build their own single sign-on systems. And I think that’s a huge help. And I also think that the implementation is very pragmatic, especially the 1.0 spec. We’re going to work with what’s there, we’re going to make a few hacks, and it works. There’s not too much to it, and somebody could implement that in a very short period of time. I’m a little disconcerned about the direction the next evolution of the spec is taking. Usually when somebody sees a good, simple thing, they’re like, “Great, this is so simple, it just works. Let’s make it complex and screw it up.” [laughter] I don’t want to say that’s what’s happening, because smart people are involved, and I’m sure we’re going to end up with something nice, but SOAP started out being kind of simple. 44:27

Jamie: I was waiting for you to say that. 46:02

David: It’s not so today. It’s completely fucked up by all the complexity being added into the mix. And in some ways, that just comes from people’s natural enthusiasm. They see something they like, and, “Hey, what if it also had a horn on this side?” I mean, it doesn’t need a horn on this side. Just let it be what it is. We get that all the time with our applications. I really love Basecamp. It’s wonderful, and people understand it right away, and I don’t need to train people, and it’s so simple. And by the way, could you please add Gantt charts, critical path calculations, and these three other things? That’d be perfect. It’s so funny. A lot of people can’t see the disconnect. You like this because it doesn’t do all these things. If you started adding all these things back in, you wouldn’t like it. And you want five things. If we said yes to all the people who want those five things, it’d be this honking monster. I think it’s called SharePoint. [laughter] And I mean, that’s just not the kind of work we do. And that’s the whole notion of not only the work we do with 37signals, but I think with Rails, too, is we try not to work on the request of customers or people. Don’t do what they say. Do what they need. So you work on behalf of somebody. You try to understand what are the underlying concepts of what they’re trying to do. And unfortunately, it works in the sense of you get an application that a lot of people like, but they can’t necessarily put their finger on why they like it. And if you try to explain to them why it is that they like it, they think you’re arrogant. They think you’re being paternalistic. They think you’re trying to make decisions of what’s better for them. And in some ways, frankly, you are. Because a lot of people just don’t know what’s good for them. And hey, that’s just not something a lot of people want to hear. But they want to hear that my needs are important and we value all your contributions. And we do. As we say, we listen to everybody. That goes for Rails, it goes for 37 Signals, it goes for pretty much anything. We listen to what people say. We just don’t necessarily agree. And people have a very hard time understanding it. They understand it, they just don’t agree. Customers in particular, and even not customers, people just using Rails, if they have a request for something and you say, “That’s interesting, but I don’t agree. That’s not going to happen.” You’re an arrogant prick for turning them down. They wanted something, and why are you not doing it right now? So that’s kind of just the flip side of what you have to just be able to put up with if you really want to work on behalf of somebody rather than on the request of somebody. 46:04

Jamie: Also called building great products. Question? 48:57

Audience: With the ease of use of OpenID, do you see the web applications having a problem of creating a distinction between using it as an identification and not as an authentication? 49:02

Jamie: So the question was, with OpenID being so easy, do you worry about the use of authentication versus kind of a title-less management? Did I get that right? 49:12

Audience: Using it to identify a person instead of proving that it’s them. 49:24

David: I don’t care one way or the other. To me, it’s kind of all the same. And we use it for identification and authentication. When we look somebody up as authenticating with OpenID, we use their OpenID to look up who they are. It’s more than just– they don’t have a separate thing to identify themselves. They have their identity URL. So in some ways, that’s the whole authentication thing. There’s a lot of people who thought a lot about it, and that’s great. I think what’s good about OpenID in its current form is that it feels like this was just somebody who needed to get some stuff done. Didn’t necessarily need to think that much about the conceptual differences between the different aspects of it. And that, I think, makes it simple. Versus a lot of other authentication approaches that have been proposed by people who really know a lot about authentication end up being very complex because it relies on a lot of this deeper understanding. I think that’s kind of the special gift you get when you jump into some niche or some culture and you don’t really fully understand what’s going on. You tend to demolish a lot of preconceptions about how things should work. When I first came to Ruby, I didn’t really understand Ruby. So I just wanted– why couldn’t this be different? Why is the web stuff not like this? And I did a lot of things to change Ruby in some ways to make it work like I thought it should work because I didn’t understand it all. If I understood it all, I’d say, “Yeah, that is kind of a pain point, “but I understand why it is for this and this reason.” And you get to be too sympathetic to complexities. Once you understand something to the core, it’s very hard to change it, I find. Anyway. 49:29

Jamie: Rails has been adopted with wild abandon in the open source community. It’s growing extremely fast. But we’re just now starting to see Rails getting into the enterprise. What do you think about that? Is that for you at all? Do you cheer, say, “Hey, that’s great”? What do you think? 51:31

David: I think that programmers anywhere being more happy because they use Rails, I think that’s great. People who want to get Rails into the enterprise and feel that Rails needs to become enterprise-ready software to do that, it’s not so great. The whole enterprise-ready thing, I think, is a big crock. To me, enterprise is a bad word. If you call something enterprise, you better be able to get your hands up. That’s an insult. That’s picking a fight. If you call my software enterprise, I’m not going to take that lightly. I find enterprise to mean overpriced, overcomplex, and not really that useful. I think that enterprise is usually something that happens when people need to use something or different from the people who commission something. People buy something for other people to use. They love enterprise. Enterprise is golf and sticks and strippers and hookers and expense accounts. That’s awesome. What’s that like about enterprise? People taking you out on their dime and kissing your ass? That’s awesome. You just happen to end up with the software that these guys produced, which is not so awesome. But what do you care? I think that’s a big part of why enterprise works. I don’t have an expense account to wine and die on, and frankly, I don’t care. We’re not playing the same game. That’s just how it’s different. I think that’s good. I think it’s awesome if enterprise customers want to use Rails, but maybe they should realize or at least sympathize with why it is that they want to use it in the first place and not just buy another package from, insert favorite paint enterprise producer. I’m not going to name anybody. That’s the reason I got attracted to it in the first place, because it wasn’t all of these things that they already have. And that’s painting a brush, I know, and stereotypes are more fun than delicate realities, and that’s what I have for a two-minute answer. 51:54

Jamie: We’re going to wrap up, but I wanted to ask two quick questions before we wrap up. And also thank you for the time and for your answers. One, I was curious to know what you thought about being known as DHH. 54:12

David: I freaking hate it. Please stop. Being an acronym, I can’t think of something worse. Like, CRM is an acronym, and I hate that. Being your own acronym sucks. My name is David, and that’s not that hard to say. 54:32

Jamie: I was just curious, I mean, you’re a young man, you’ve done a lot, you’ve created this thing that is changing a lot of environments, changing how developers are working in a lot of areas. What’s next? What’s next for you? What are your thoughts? What do you look out 10, 20 years and say, “Where am I at that point?” 54:49

David: I don’t. I think plans are for fools. For that kind of look out, I didn’t know where I was going to be two years ago, and if I thought I knew, I probably wouldn’t be this. And I probably would rather want this than what I thought two years ago would be a nice place to be. So I try to make no plans. I try to just enjoy what I do right now, and perhaps next week. That’s a pretty good plan. “What do I need to do next week?” Kind of like that. Longer than that, it’s just guessing, and that’s just not that interesting. It’s much more fun just doing something and trying to hypothesize what the future’s going to look like. 55:11

Jamie: Well, thank you. 55:52

Audience: [applause] [applause continues] [applause continues] [applause continues] [APPLAUSE] 55:54

See LinkedIn discussion via Jeff Lin on this session.