Optimize for now!

http://www.37signals.com/svn/posts/896-optimize-for-now

by naish • 18 years ago

72 34 18 years ago

redorb• 18 years ago

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)

mynameishere• 18 years ago

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.

yters7• 18 years ago

And you've just described a whole industry called "self help."

curi6• 18 years ago

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.

jsmcgd• 18 years ago

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.

domnit• 18 years ago

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.

apathy2• 18 years ago

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

coglethorpe• 18 years ago

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.

cantfindlogin• 18 years ago

The 15th Richest Man in Australia would beat you up for that one.... "He started his Linfox company in 1956 with 1 truck. [6]"

http://en.wikipedia.org/wiki/Lindsay_Fox

I saw his interview with Andrew Denton a few months ago.. interesting guy - very much a working class straight shooter who's done well for himself..

*That wikipedia article has about 3 mentions of "suspicious fires".. It's really piqued my interest - but I probably should get back to coding..

wallflower• 18 years ago

As did billionaire Wayne Huizenga, who started behemoth Waste Management with one garbage truck

jey• 18 years ago

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

sanj2• 18 years ago

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• 18 years ago

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!'

apathy2• 18 years ago

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.

bayareaguy• 18 years ago

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.

sanj2• 18 years ago

It seems like there needs to be a list of these.

In another thread:

http://news.ycombinator.com/item?id=131216

t0pj• 18 years ago

Nothing like "jumping the shard", aye?

hernan7• 18 years ago

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

dfj225• 18 years ago

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.

aneesh• 18 years ago

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• 18 years ago

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

cousin_it• 18 years ago

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.

jcromartie• 18 years ago

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.

Optimize for now!

Related Stories