We started on a single server for everything when Basecamp was first launched. There was no point in growing a huge farm of machines if the thing was going to flop anyway.
It's this sort of thing that drives me nuts about the 37signals' blog. Let me rephrase it:
When I started my trucking company, it was a one-man venture. So, I only bought one truck, since that's the most I could drive myself at the same time. Buying a whole fleet of trucks would not have made sense.
Just because advice is correct doesn't mean it's useful. Something can be very correct and still very stupid.
Continuing your analogy, there are plenty of people out there who would start their trucking business by buying more than one truck and then trying to find people to drive them and things to move.
The great thing about the 37signals blog is that it is reminds us to keep things simple. Don't over complicate things just because we can. I think there are times when all of us can benefit from having this spelled out to us.
Articles like this need to be written because common sense isn't common. It seems obvious to us not to buy too much for a business, but many businesses have gone under by going too far too fast. They buy too much equipment, far more than they need and run out of cash.
I've seen software projects crippled because the managers wanted to optimize for a later that never would happen. Coders often make code work, then make the code better. Others don't always seem to get that concept.
What the advice misses is that even at an early stage, you need decisions in place that allow scaling. For example, if you buy 1 truck for your one-person shipping company, you can move 1 container at a time. Adding a second truck lets you move 2 containers. 37signals is smart--they built their software so that it could grow to 2 servers--but they left that out of their advice. There must be a path from simple to complex.
> they built their software so that it could grow to 2 servers
This is somewhat debatable -- all software can be grown to multiple nodes, it's more a question of how much work is involved.
They built their software to meet needs. Then, later on, they worried about the other stuff. That's a good way to determine whether the other stuff is worth worrying about.
See also the WebVan analogy for an example of the converse.
"When I started my trucking company, it was a one-man venture. So, I only bought one truck, since that's the most I could drive myself at the same time. Buying a whole fleet of trucks would not have made sense."
Apparently that wasn't so obvious to the guys who started WebVan.
No way. The "self help" industry is not full of correct but obvious advice. Lots of it is wrong and harmful advice. Including most books about dieting or parenting.
What was the deal with that thread? First, there was that string of downmods, then suddenly the whole thing goes dead and you also lose your voting privilege. I had thought the whole thing was in jest, including the rampant downmodding, but apparently people were taking it seriously. But why? Did it seem like we were actually fighting?
No one bothered to tell me why I can't vote now -- i just had to notice that when i refresh the page the number goes back down 1 -- but my guess is that it's the same reason as rms: upmodding.
I kinda upmodded your entire comment history. But i read it first and liked them all, so I don't see the problem...
I thought that thread was all in good fun between us, but wasn't sure why people were downmodding it. Don't know why it went dead either. But it might have been dead for a while and we didn't notice -- maybe it only tells you your thread is dead when it's old.
Better threads than that have been turned dead. Meh.
PS did you get the email asking for your AIM account? then we could speculate about why pg kills threads and bans users from voting where pg won't read it and possibly get annoyed and possibly mark it dead too.
I thought someone was upmodding my comment history. Well, once enough people read that, my comment history will be downmodded a couple times, so I guess it works out in the end.
Definitely. There are a couple philosophical discussions I am participating in which require long, drawn out replies, while my yc posts are generally very short.
Yes it will, if you break it up onto multiple shared memcached servers. Or re-think how you're serializing it. Or why. Or use a distributed hash table (although if you own all the machines, memcached is easier and faster to ramp up).
Basically, all of these exceptions people are cleverly bringing up are exactly the sorts of things that get in the way. Do everything well enough to get a usable product. Throw it out in front of customers. If you need to make it better because people are beating down the door, go for it; that's a much better problem to have than a scalable but unused resource soaking up your operational budget.
Agreed. I'd add linear lookups to that list since they easily lead to n^2 when someone comes along later on and puts your lookup inside a loop of their own.
I couldn't agree more. Needing to scale up is a GOOD problem to have. Many startups don't make it to that stage. Plan for the future (ie have room, and ways to get money for more servers), but don't live in the future (don't grow a server farm from day 1).
This seems like good advice, but to me it would be interesting to read about what can be done to minimize growing pains.
If a developer only focuses on the immediate future, it seems like they could be caught off guard in the case of rapid growth. This might leave them scrambling while their app crawls and users become upset (or decide to use something else) because things are unresponsive. Twitter comes to mind here.
Just today I was talking to a team lead here about abstracting away from a truly terribly proprietary template language for a CMS. His first thought was "that's a good idea, but we'd have to make sure it would be easy to move that code to a different CMS in the future." There's just no way to make that happen, so the idea probably won't get off the ground because management wants things future-proof.
I see where they are coming from, but it means everybody suffers instead of just enjoying improvements in the present.
Smart strategy, build what you while you can and scale as you need. (this falls inline with PG's launch early and often and also the cost of a startup is low with this idea)
On my project I put a lot of effort into scalability: the typical use case involves no running code on the server, only static content. With just tens of users so far, in retrospect I should have given more work to my PR skills.
It's this sort of thing that drives me nuts about the 37signals' blog. Let me rephrase it:
When I started my trucking company, it was a one-man venture. So, I only bought one truck, since that's the most I could drive myself at the same time. Buying a whole fleet of trucks would not have made sense.
Just because advice is correct doesn't mean it's useful. Something can be very correct and still very stupid.