Om and I interviewed Jason Fried and David Heinemeier Hansson of 37signals as a bonus PodSession this week. 37signals is a 7-person hosted software shop based in Chicago. Their current products are focused on project management and personal life management. David Heinemeier Hansson is the lead developer of the Ruby on Rails framework.
Our discussion focused on scalability, the tools needed to get the job done right, and how small businesses can better plan to succeed. The interview was conducted via a telephone conference call.
Our interview with Jason Fried and David Heinemeier Hansson is 29 minutes and 50 seconds in length and a 13.7 MB download.
Topics
- Are companies building to scale? When does it pay to plan ahead? Are companies currently being built to flip and not worry about scaling?
- How does Ruby on Rails help you think ahead and build more scalable code?
- Ruby on Rails version 1.0 will be released this week. What is new in this version and what can users and developers look forward to?
- What are some of your favorite products that use Ruby on Rails? Blinksale, an invoicing tool written in Rails.
- When will Ruby on Rails and software such as Typo become more mainstream and used to power more blog sites?
- What tips do you have for people thinking of starting a company?
You can stay up-to-date with Jason, David, and the rest of the rest of the 37signals on their weblog, Signal vs. Noise.
Transcript
Niall Kennedy
Hi this is Niall Kennedy.
Om Malik
I'm Om Malik.
Niall
And you're listening to the Om and Niall PodSessions. Today we have 37 Signals on the line with us, we're trying something new today, and doing an interview and a conversation. How about everyone introduce themselves on the line.
Jason Fried
Sure. Hi, I'm Jason Fried from 37 Signals.
David Heinemeier Hansson
I am David Heinemeier Hansson, also from 37 Signals.
Om
Well, you guys know me so, no introductions needed. Right?
So what are we talking about today? I think Niall and I discussed this with you, Jason. We were going to focus on our hotly debated issue of scale and scalability, in a kind of little riff on Jane Austin there.
Jason
Yeah, I guess all this probably came about from the blog post that you put up and we responded to. And so Om why don't you tell me a little about why, why you think that scale is something that everyone seems to be ignoring and why that's a problem.
Om
OK, so that's one of the things that you and a lot of other people don't understand. What I was trying to say was that this is not about adding servers or buying bandwidth, this was basically thinking through your product, thinking through your product strategy and where you will be, and architecting your very innards accordingly. This was not about buying $3 million servers or anything of that sort. This was mostly about thinking through where the company was headed, where the product was headed, and giving some thought to how much do you want to scale.
Now the problem I have is that many companies I meet on a daily basis and the so-called "Web 2.0 companies," they're basically patching things together and the whole concept is if you can do this and if you get some early traction in the market, there's a good chance that you can be flipped for a few million dollars. Now I have a problem with that, and I think that's what I talk about scale and scalability. I didn't want to make this a religious issue, but apparently it's become so.
Jason
David, why don't you jump in first from the software side.
David
I think that the problem with that notion is that the fallacy that you can do this, that you can architect something scalable from day one and that's a good idea. It's a pretty dangerous idea that leads people to think that if they just think hard enough about the problem up front, they can solve it. And I think if you talk to pretty much any of the major operations that have scaled high and low, they'll tell you that they could not have foreseen the effects on the system once users start coming in in droves.
I think Dare Obasanjo from Microsoft touched on this and how they scaled up MSN Spaces over a year to be three times the size of Live Journal. And as you said, they basically had to rewrite everything as they learned about what the issues are. I think that's the key issue is that you cannot foresee what kind of scalability you'll have because real users, real data just have a tendency not to fall into neatly set up simulations, which means if you spend a whole lot of time up front doing what you think is needed to scale, you're going to spend a lot of resources on something that might not turn out in the end to be what you needed. Which means that you started out spending a whole lot of time and money on something that's never going to be used, and you're going to have to re-architect your application anyway.
So it seems like it's kind of placing a pretty high risk bet, and a pretty high risk bet in the sense that the time you're spending thinking about and optimizing for scalability is time you're not spending thinking about, 'how could we improve the application so we'll actually have scalability problems.' I think that people should focus more on trying to get the scalability problems in the first place, of course meaning getting users who care enough the application to use it.
Jason
That's my biggest thing, at the end of what David said, kind of the opportunity cost. When you focus too much time on the future, you're obviously not able to spend time right now and do what really needs to be done now and that's building a great project, a great experience, and making sure the copyrighting is solid, the interfaces are solid, the marketing is solid, so you will have a scalability problem.
You actually want to have a scalability problem. I think that's the real goal nowadays is being able to build something that's going to have a problem scaling because you have so many people using it. Now, of course, the other thing -- and this is something that I do agree with you about -- was this idea of companies not thinking too far ahead, and in general I think it's good not to think too far ahead.
But when you take a company like Flickr that's giving away free photo hosting, they're clearly going to have a hard time scaling that if it's free. It's in fashion right now to give away a gigabyte of space: "let's just give away a bunch of space and let's just see what happens." And I think that's where you start to get in trouble, where you start giving everything away for free, and trying to figure out how to pay for it later.
And so I think that's definitely a problem, and I think that Flickr may have run into that problem as they ballooned in size. Luckily a lot of these companies, us and del.icio.us even though they just sold, but a lot of these companies are dealing with text based data which is pretty easy to scale with. Also, if you charge right off the bat for your services you can scale indefinitely because it's profitable to scale. I think the problem is where it's not profitable to scale, that's when you start running into these problems.
David
Yeah, I agree with that. That's actually when what you want is not technical scalability, you want a business model scalability, like what are you going to do if 100, 000 people actually do come to your site? Are you going to have enough money to buy the servers needed, and so on. It's not about the technical issues; it's about making each request worth it. If you give away everything for free that's of course pretty hard.
Niall
I hear two things coming from you guys: one is to not focus on what exactly will be the feature that you want to scale because you don't know when you launch what will be the most popular feature that you're going to want to go back and re-engineer to create the best user experience, and the other thing that I'm hearing is about the business experience.
We talked about startups wanting to just flip, and part of the interesting thing about giving things away is you gain many users, and Om's done his monetization of the eyeballs piece that will try and prove that it's $35 for every user that you sign up, and it's a little bit more difficult to do that with future service at $5 a month. So doesn't that fall into the whole built-to-flip model when you're trying to get all the users you can without worrying about scalability?
Jason
Well, I would say if your strategy is a build-to-flip, you've got to come up with a better strategy than that. I think a flip should be a pleasant side effect of being really successful. But if you're building something to sell it, you're putting a lot of eggs in one basket there. You've got to deal with the economy.
Google might decide to stop buying people; Yahoo might decide to stop buying people. You have to deal with the stock market; you have to deal with all sorts of market forces that you clearly have to deal with anyway when you have a product. But if you have a product that you're selling and you have your own revenue coming in, you have a little bit more control over your destiny than hoping someone's going to buy you.
I think anyone right now who is building to flip, and they're getting into this business just to build something so Yahoo will buy it is making a very dangerous mistake.
David
I think that it's pretty dangerous too to put a price something like $35 on a pair of eyeballs. I think that is not something that is going to fly in the long term. Jason Concannon from Weblogs Inc had a great post about this and about how they sold and what that turned out to be. In his notion, of course it was all about the revenues, and as he calculated it the price was more like two dollars per user, and that was not based on an intrinsic value of per user, but just on the amount of advertising that could be sold on that pair of eyeballs.
I think that we shouldn't get too attached to the idea that getting one user's worth of $35 is a pretty dangerous generalization.
Jason
One other thing that I'll throw in there real quick is that I don't know of any great company, ever, that was built to be sold. If you want to build a great company, you have to build a great company. You shouldn't be building something to sell it to somebody else. Again, if it gets sold and you're happy to sell, that's great, but to have that as your motivation ' to build something to sell something ' to me, by default means you're not going to build something great, you're just going to build something that someone else wants to buy.
And of course, everyone has different motives. Our motive is to build great products and to build a great company. Someone else's motive might be to sell it, but I think selling things is much harder than everyone thinks too. I don't think Yahoo just comes over and drops a blank check on you and says, "Hey thanks, now we have tagging here and there." It can certainly happen but it's very rare.
Om
There are a couple of things. First of all, the story which I did was $38 for a set of eyeballs, was actually an aggregate of a past-tense of deals which happened and we based it on that. I think everybody focused on that whole issue and never really read the entire story which was about: the whole concept is not all eyeballs are created equal. Some are more valuable, some are less valuable.
And there was a very categorical statement I made in the story that was, if you don't have revenue and you don't have a community which is sticky and is more loyal just the way MySpace was, there is very little value to those patriots. However, the other issue which is the build-to-flip, the issue which I talk about.
One of the reasons I wrote that post is pretty clear is that: look, you guys have a product, you have a product strategy, when you build the product it's almost 95% there. And then you're taking the user feedback and kind of tweaking it, right, either the alpha or the beta users. Now this whole concept of perpetual data, people just keeping things out, not knowing where things are going.
I give you the example of Flickr. Two years ago a lot of the features they had are a lot of the features they have right now. They've made incremental improvements. They thought it through: what they wanted their product to look like, and they were flexible enough to adapt, change, morph as the community reacted. It was not about going into a perpetual beta and saying, "We keep changing our game all the way through."
So those are the issues I have when I say scale and scalability, the build-to-flip model being abused completely, now everybody's doing it and I think those are the issues which are very important. One needs to address those things, and a lot of people, maybe perhaps it's a lack of my own writing skills that I could not articulate as clearly now.
Niall
I don't think that's the case, I think you're a good writer. I think what you just said goes against your original point, which, using the Flickr example, which was they've been adjusting, adapting as have we all the time. I do think things are in perpetual development. I don't like the word 'beta;' I think it's kind of ridiculous, so I just call it like development. I mean things are being developed and improved all the time.
But, that's the exact reason why you shouldn't spend a whole lot of money up front to build this system to scale because the system may change. In six months, your users may take you in a completely different direction and then you've spent X amount of dollars and time on making sure things are going to work the other way.
And now things are different, and so I think that's a great example of why, if you're a flexible company, you shouldn't worry about predicting the future too far in advance because you're just going to end up spending ' and forget the money side of it, it's just time, and time of course is money ' but really it's time and opportunity costs, not being able to do other things that really matter right now.
David
And also, the more time you spend on optimization and scalability and so on, the more you freeze your current architecture, so it's kind of like putting your clay in the oven when you start adding optimizations because these optimizations are usually something that goes against the grain of good software development in general about having readable code, maintainable code, code you can change.
Because often times what's scalable or highly optimized needs to have bulky hacks, needs to go shortcuts through the system, and the more of these optimizations you add to the system, the more brittle it will be and the harder it will be to change and add new features to it.
So I think in software development there's this notion of premature optimization being the root of all evil, and I think that applies pretty well in this example too simply because you can't optimize something before you know what the problem is. And once you do, you've tunnel-locked yourself into that solution, more so than you were before and that's just a dangerous path to go down unless you very much have to. I think that's what the great thing Jason: ...problem is. And what you do is, you've locked yourself into that solution, more so than you were before. That's just a dangerous path to go down, unless you very much have to. And I think that's the great thing about the web, and the great thing about being in internal development, is that you can react to problems as they arrive. I mean, we didn't do, with basecamp, or the any other projects, we didn't spend a lot of time upfront thinking about all these capability issues. We found the problems as they arose, and then we dealt with them. And I think that is simply because you can now. It was different in the old days when you shipped a new CD every year, and you had to make sure that that shipment was solid, and that it could last for years. Now you have so much more flexibility, which totally changes how you go about software development, and it totally changes when you need to do optimizations, and when you need to worry about all these things. You can now push the problems out until they're actually real problems, and that's where you have the most information available about the problem, and that's when you have the most context available to actually solve the problem. So you're just setting yourself up for an easier living if you can actually wait until you actually have problems to solve it.
Om
Ok, I think we should switch gears here. I have some questions about working on Ruby on Rails, and if that is...
Niall
Yeah, do you think that Ruby helped solve some of the problems, having that type of NPC architecture, and helping you think ahead of time helped you thinking ahead of time helped promote available solutions....
Jason
yeah, I definitely agree that different platforms will have different intrinsic capabilities of scaling. Ruby on Rails is very similar to the LAN stack, in the sense that PHP and Python and Pearl and so on, they all have roughly the same approach to scaling, which is the notion of scaled nothing, where you can add as many web servers and as many application servers as you want by pushing all this data, all the sessions, all the stored data down to some data layer, like a data base. When you have an architecture like that, scaling is a solved problem in the sense that...how yahoo scales, or how livejournal scales, or any of the big LAN stacks sized scale, on a relative scale, how just PHPs in general scale, it just means that the problem is solved in the sense of throwing more hardware in there. There's a path ahead, which means that if you have more problems, you know how to add more hardware in order to solve that problem. That doesn't mean that you never have to optimize your software and never should, just that you're not locked into a box that says this can only scale to 2000 uses and then there's nothing we can do, there's no more hardware we can add. I think that comes back to the key issue, which is, are you making each request worth it? Like, with Faith Campbell we paying customers, by the time we have scalability problems, we will have more than enough revenue to pay for new servers. If your model doesn't have any revenue built into it, then that's putting you at more of a problem. You can't just keep buying new servers if you're not any revenue in. And then I can see, you might have scalability problems, simply because you can't afford to scale. But that's not a failure of technology but a failure of business.
Om
Right. One thing I think, David you mentioned, was that there was an upgrade coming to Ruby on Rails, and I just was wondering what that's all about.
Jason
Yeah, David can talk on that but basically Rails 1.0 is due out what... hopefully next week, maybe?
David
Tuesday. Tuesday is the target right now. So the software is basically right in... we're currently putting the final touches on the new website. It's more of a monumental cultural event more than it's a monumental technical event, since Rails has been at 1.0 since at the beginning of the year. Meaning new changes that we've introduced have kept backwards compatibility. So, what's in 1.0 what it's going to do really now if you're already on Rails it's mostly about the final [box mixes]. We have a whole lot of new features in store, but we're holding those back to the 1.1 release. Now it's just about getting a nice polished 1.0 version out and getting a new web site and getting some refreshed imagining to it.
Om
Explain to me why when the new version of Ruby comes out it will make life a lot easier, I mean, how the user will be impacted, that's what I'd like to know.
David
If you're already using Ruby on Rails, the new release won't impact you unless you unless you hit one of the parts we've fixed. The major change, the major thing is that we now trust enough in it to put on the 1.0 label, which is more about a feel of quality control of our personal and professional pride that we now want to call this project 1.0. And that's more sending a signal, so if you're risk adverse, and don't want to fool around with software that doesn't have a 1.0 label on it, now that's not an issue. So I think those concerns in general, if not silly, then are overrated. But that's how I feel, and that's the reality, so we are defiantly happy to not have that be an issue anymore.
Niall
Alright. What are some of your favorite Rails services that are out there right now, that have caught your interest?
Jason
Rails based products?
Niall
Yeah.
Jason
I'm a big fan of Blinksale, which is by Firewheel Design. Blinksale.com, it's an online invoicing tool. We don't actually use it much because we don't send invoices out much anymore, but I've looked through it and I did actually send a few samples invoices out. I just really liked the flow, I really like the way it works. And of course, what I think is really important here is that technology doesn't make these products. There's no rocket science Basecamp, there's no rocket science in Blinksale, there's no rocket science in Odeo or anything like that. It's not Rails that really... Rails isn't doing anything special, Rails just makes things easier to program, so it just makes it easier to write these products, and you can worry about what makes your products unique rather than worrying about all the monotonous things you do over and over and over. You could build Basecamp in PHP you could build Blinksale in PHP or Perl or whatever you want. It's more of a...David could talk on this too, it's more of just like loving the language that you're writing in, and loving the development process, that basically results in creating better products. If you don't treat programming as a chore, instead you treat it like a love, treat it like something that you just really like to do. You're just going to build better products by default. So I do think that Rails has that special quality to it where people actually enjoy programming in it. It also seems to be a language that people who haven't really programmed very much in the past can kind of get into it. Some people call it a language for designers, which I don't really understand, but I think that the idea is that it doesn't feel like a programming language to someone who is not a programmer. I think you can read the code a little bit there. I don't program, you might be able to tell that from my answer here. But I can read through a lot of the code, the Ruby code, that David and James and the other guys have program, and I can read it and kind of understand it because it almost reads like English, it's logical. And I think that this also makes products easier to design for designers because you can look at the code and understand what it'd doing, and you can almost work with it that way without having to go back to someone and say well, "what did this do, what did that do?" So I think one of the nice things about a lot of Ruby apps or a lot of Rails aps is that there seems to be a focus on good interfaces now, coming out of the Ruby on Rails based software, for whatever reason. I think part of it has to do with the fact that designers, it's just easier for designers to work with programs that are written in Rail, than in PHP or something else.
Om
Have you been playing around with typo and you have some questions I assume, on this and you've have had some issues...
Niall
Let's not make this aabout tech support, let's keep talking.
Om
Oh no, no no! I actually wanted to get to is... how long before Ruby starts to make an impact for bloggers, and for people who are leading the whole open-media revolution.
Jason
I think that the thing about Rails in general is that it's not as well suited as PHP for packaging up and distributing to run on any imaginal hosts, just because there is more stuff involved. And that more stuff makes it harder to currently distribute these applications in a way that makes them easy to install for people who are not technically savvy. And I think that's what PHP is really great at, the distribution of it and the adoption is large enough that people that don't know anything, or much about programming or technical issues can kind of huddle along and get WordPress installed somewhere. So I don't think... it's going to be a while before Rails is going to have an impact there. But, on the other hand, a lot of the most popular services are not like that. Most bloggers are not installing their own blogging software. They're using TypePad their using blogger, they're using WordPress.com, where you get this host immersion, and I think that it's not going to be too long until someone announces some platform like that running on Ruby on Rails. And as soon as you do that, who cares what it's running on? And then, Ruby on Rails can take their competitive advantage for getting stuff done faster. So I don't think the technical issues of that will have that... Do bloggers care? I think bloggers care about great applications, and if somebody launches a blogging service on Ruby on Rails that's just better than the other stuff, that's when people will start caring, not because it's simply written in Ruby on Rails.
Niall
OK, well we're almost out of time. I have just one more question for you guys. For a start ups in small businesses what tips would you like to send out for people to watch out for as they start their own business.
Jason
One thing I alluded to earlier, and I'll repeat it now, is this idea if you are going to build a business, and I'll underline the word business, you gotta have an idea of how you are going to make some money. It's fun to be an idealist when it comes to building something and thinking you're going to be bought out for 50 million or whatever, but in the mean time you have to run a business that can survive if no one buys you. And if you're not running a business that can survive in that way, then you're really not running a business, you're just building a hobby site, which is fine too, if that's your motive, that's totally fine. So I would say that's the first thing. The second thing is, you have to embrace constraints, don't try and push constraints out of the way. So don't go out and get venture funding. You know, it's better to have less money when you start out. Don't go out and hire a bunch of people, it's better to have less people when you start out. Do stuff on the side, as a part time job to build your application, don't necessarily dedicate full time to building something, its better when you have less time to do things, because you'll spend that time more wisely. So, look for constraints and embrace them, instead of trying to push them out of the way. I know a lot of companies spend a lot of time and resources and money seeing an obstacle and trying to get rid of it, instead just working through it and working around it. I think that that is when creative things happen, is when there is constraints in place. So, again, my two pieces of advice would be: if you're going to build a business, you have to build a business, and a business has revenues, and hopefully profits. So work on that first. And second of all you gotta embrace constraints and really work within your limits and not try and do something that's kind of above and beyond what you're really able to do. Don't try to push those things out of the way. In fact, you want to look for more constraints; it helps force you into better, simpler products and simpler solutions. So those are my two big things, I don't know if David you have any?
David
I think just in a technical issue, you should start caring about what we call the epicenter of your application. The stuff that your application really does. Don't start out making a logging system, or making that all that around stuff that's not particular to your application. You should spend the first hours of sitting at the keyboard on the stuff that makes your application special, and worry a whole lot less about all the generic stuff that you need at the end. So worry about the particulars of your application and get that right before staring to do all the other stuff.
Om Malik
Alright. Hey guys, thank you so much for your time today. I thoroughly enjoyed it. Thank you to you. Hey Jason thanks for keeping it civilized, even though you and I fight all the time.
Jason
Well, I think if we were in the same room it wouldn't be civilized.
Well, thanks for having us on, we definitely enjoyed it. You know, I think it's cool, actually, that we can disagree and be civil about it. I think a lot of times, especially on the web, that people start flinging mud back and forth because there is this level of anonymity, that no one has to worry about... no one really knows who you are and you can sit on your couch and rip on people, so, I think it's good.
Om
Goodnight.
Niall
Alright guys
Jason
See-ya.
