Hacker News Reader

> I've never understood this "don't obsess about performance at the start" rule.

It helps if you've seen, firsthand, a startup wasting time worrying about trying to optimize stuff they don't even know if they're going to need to optimize.

> my iPhone app starts up 5 seconds quicker

That's something you know you need right away, apparently. It's probably a sensible investment.

> Or as great as PostgreSQL is for single server deployment why wouldn't I look at something easier to manage, trivial to scale and a more agile schema like a DynamoDB, MongoHQ, Cassandra.

Because there are some big tradeoffs involved in using those. And because Postgres is not at all hard to manage or scale to a point where you can probably afford to look into other solutions or hire someone to scale it. This article is, after all, written by an Instagram guy, and they seemed to do ok with Postgres in terms of scaling.

That's not to say you shouldn't think about it at all, but there are so many unknowns that it often makes much more sense to spend time doing market experiments rather than technology experiments.

Simply because it's never a case of spending "a few extra hours" when learning and evaluating a new tool. There are many "unseen" hours in troubleshooting, monkey patching, and re-evaluation. These are real costs that can be avoided by defaulting to known best practices (at the expense of ultimate performance).

Worked with friend on a new idea (while also trying new tech across the board), ended up in this: http://simondlr.com/post/26360955465/dynamodb-is-awesome-but When we got traction, we wanted to change databases, but because it was just a weekend hack no one wanted to spend time doing it and eventually killed the app. It was our own doing of course (choosing new tech to work with). But yes. Work with what you know when testing ideas, unless you also want to play with new tech.

Right. So then the mantra should be "pick the technology stack you know best" as opposed to "don't obsess about performance". They aren't the same thing.

"don't obsess" is much different than "don't consider".

It's dangerous to prematurely over-optimize, as the OP says, but it's never a bad thing to think about optimization. Otherwise you'll end up with crap.

As another responded mentioned, I think the key here is that word "obsess". I'm personally of the belief that the "premature optimization is the root of all evil" camp goes way overboard. Especially for web sites since getting a "reddit blackout" means thousands, maybe millions of people probably aren't going to bother about your site ever again. However, I personally allocate a certain amount of my time on getting a fast solution but when it gets into serious tweaking, it's time to decide if you're ever going to have a traffic spike.

I'd personally say, go as fast as you can without having to work hard for it. But as others have mentioned, picking something with a lot of options and not coding inefficiently (e.g. don't use associate lists for everything when you know this should be a dictionary).

I agree with you.. something else to keep in mind is that a lot of these startups have millions in funding too. If you're bootstrapping you can't afford to just rely on cloud services like AWS.

Picking the right infrastructure DOES matter if you're hosting it in 1 machine in your basement. It matters less when you got millions in funding, a team of developers, and machines with 32 GB of RAM in your disposal.

> something easier to manage, trivial to scale and a more agile schema [than PostgreSQL]

Not enforcing the schema for your data is one of the riskiest optimizations you can make; it lets any bug start irreversibly poisoning your data for however long it takes you to realize it.

Premature optimization is the root of all evil -- DonaldKnuth

More information here: http://c2.com/cgi/wiki?PrematureOptimization

If you are scraping for dollars on budget VPS and the optimization is easy without any tradeoffs, it's a no-brainer.

I hope you appreciate that this does not represent all or even most real problems.

The premature optimization is evil meme has just been pushed beyond reason, that's all. People blindly insist that it is cheaper to just throw hardware at it then waste "precious developer time" on making things fast. But in most cases, a few hours of time spent up front making sure you aren't doing horribly slow things can save you hundreds of thousands of dollars in hosting expenses. I have not met any developers getting paid $100k/hour.

>Or as great as PostgreSQL is for single server deployment why wouldn't I look at something easier to manage, trivial to scale and a more agile schema like a DynamoDB, MongoHQ, Cassandra

That has nothing to do with premature optimization, that is just about using unproven data stores because you didn't bother to read the label.