I've never understood this "don't obsess about performance at the start" rule.
Is it really that much of a problem spending a few extra hours prototyping different solutions and factoring in performance from the start. Why wouldn't I pick Vertx over Play if it 2-3x faster with similar productivity. That's money not spend on VPSs that can be used for marketing.
Likewise why wouldn't I look at a binary serialization format if it means my iPhone app starts up 5 seconds quicker. Users decide whether or not your app is worth keeping in those few seconds of starting the app. Why not spend time trying to keep them ?
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. Especially if I am a single person startup.
I understand about premature optimisation but it seems to make a lot more sense to properly consider your architecture from the start rather than deferring it. Or did we all forget Digg v4 ?
> 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.
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.
Is it really that much of a problem spending a few extra hours prototyping different solutions and factoring in performance from the start. Why wouldn't I pick Vertx over Play if it 2-3x faster with similar productivity. That's money not spend on VPSs that can be used for marketing.
Likewise why wouldn't I look at a binary serialization format if it means my iPhone app starts up 5 seconds quicker. Users decide whether or not your app is worth keeping in those few seconds of starting the app. Why not spend time trying to keep them ?
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. Especially if I am a single person startup.
I understand about premature optimisation but it seems to make a lot more sense to properly consider your architecture from the start rather than deferring it. Or did we all forget Digg v4 ?