
Optimize for now! - naish
http://www.37signals.com/svn/posts/896-optimize-for-now
======
mynameishere
_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.

~~~
domnit
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.

~~~
apathy
> 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.

------
sanj
I feel like this particular piece of advice should be post-fixed with "... but
don't be stupid!"

In particular, keep an eye out for n^2 loops and the like. Watch for shard-
jumping queries. Easy stuff like that can go a long way.

~~~
mrtron
And keep a list of potential problems that won't scale.

'Hey we serialize a list of ALL users for this...that won't scale!'

~~~
apathy
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.

------
aneesh
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).

------
vegai
Good thing 37signals.com isn't in the bridge building business.

------
dfj225
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.

------
jcromartie
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.

------
redorb
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)

------
hernan7
Good post. On my personal project I am always tempted to add pointless
scaling/generalizing stuff. Shades of "worse is better"...

------
cousin_it
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.

