Optimize for now! | Hacker News Reader

Optimize for now!

37signals.com

72 pointsnaish34 comments

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.

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

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.

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

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

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

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.

Hehe, I upmodded you! Take that!

I expected no less :) I'd upmod you if I could vote.

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.

I think the points were taken away, anyway.

Well there's a Gettier problem for you:D

And, I haven't replied to your email because I only check personal email briefly on the weekends. Less distraction that way.

no problem.

personal emails are more distracting than yc? :)

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.

do you know any public places worth discussing philosophy at?

No, unfortunately I don't.

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.

Nothing like "jumping the shard", aye?

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

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.

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

In another thread:

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

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

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

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)

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

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.

Reply on news.ycombinator.com