Startups and The Problem Of Premature Scalaculation | Hacker News Reader

Startups and The Problem Of Premature Scalaculation

onstartups.com

23 pointscoderdude16 comments

It's a delicate thing to balance. If you're anything like me, this kinda premature optimization (at a micro or macro level) is a lot of fun to do. You tend to learn a ton, and it's often fun projects to help you wind down. Those are two pretty big benefits: learning and having fun.

You can also spend a bit of time and lay down a foundation. Sure, in 2 years time you might need to rip it all out but you can certainly cross your T's and dot your I's. Identify slow queries. Figure out whether you think you'll shard or replicate (or both) and whether your current architecture makes it possible. Remove state from your web servers to easily load balance them. Work towards reasonable output caching. These are all things that you can do naturally, while you code, without it being a time-sink.

I think even admittedly premature improvements of scalability are seldom a waste of time. People saying so are at least making premature generalizations.

Bombarding your app with of millions of simulated users and tweaking it to handle it well can be loads of fun. It might even provide the inspiration needed to finish the app in the first place.

Great graphic designers are at times known to indulge in pointless experiments in typography or color. Why can't great hackers indulge in pointless experiments in scalability without suffering the ridicule of their peers?

Developers acting on their own accord must be allowed to be inspired by their hopes and dreams and not always take the straightest path to the goal.

If time should always be spent in the wisest manner without indulging in your own fancy, developers should also stop write complaining blog posts about other peoples code and instead improve their own apps.

"Why can't great hackers indulge in pointless experiments in scalability without suffering the ridicule of their peers?"

There's nothing wrong with that, but you shouldn't do it with your startup. Optimization is inherently limiting -- your product will probably be completely different in three months, and you will most likely find yourself having to reverse or work-around unnecessary decisions that you made early on. I know we did, and now our engineers probably curse my name for it. It has probably cost us dozens of hours (and thousands of dollars).

"Developers acting on their own accord must be allowed to be inspired by their hopes and dreams and not always take the straightest path to the goal."

If your goal is to make awesomely scalable software and learn a lot, then, yeah. If your goal is to build a company, however, you should shed every non-essential and worry about potential problems when they're real problems.

Upvoted because I agree with the sentiments expressed within, but I think balance is called for. An early-stage startup can still be a learning experience.

I'm a pragmatic, "put it in the done basket now" kind of guy, and have argued the author's viewpoint to people over engineering things countless times. Generally I argue against the optimization route when I feel like we're facing a choice of delivering something not optimized that pleases customers, vs having something really technically cool that's only partially finished and not delivered. A lot of developers tend to fill all available space and time with useless engineering for some kind of street cred.

But there is another side of this that the author is not mentioning. For a lot of applications, if it's not going to scale properly, then the great success the company seeks becomes its most dangerous risk. This is because you often can't control the adoption rate of your application.

For many kinds of applications, once the load gets to that critical tipping point, the entire system goes into an unstoppable death spiral of doom. The whole thing won't run. For God knows how long until you do who knows what to make it go again. And what happens to your business during that time?

For some kinds of businesses, that downtime isn't too big of a deal. But for others, it could be enough to make the customers regret they ever signed up with you.

Still, premature optimization is evil, I can't deny it. I think the best solution to the quandary is to have and create tools and skills within the team such that building apps that can scale without too much danger isn't much harder than building plain apps.

I would temper this with the fact that while premature optimization is bad, writing terrible, unmaintainable, inefficient code is also bad. Ideally when building your startup technical founders write code that can eventually be scaled up or out if necessary, leveraging previous experience to do so(hopefully) as to not waste time and be able to focus on business concerns as the author suggests.

Am I the only one who initially thought this was about Scala, the language? :)

"Scalaculation" is a weird word.

i thought it would be about Scala as well.

Yea, I was also hoping for something insightful about Scala adoption. Doh!

As far as premature optimizations, if they're truly premature and moderate/high effort then yea, you're usually better off getting things working quickly first. But I've seen the admonishment of premature optimization often used to turn a blind eye on the technical debt that can result from simply going fast. Successful projects require doing the simplest thing possible that will work while maintaining a conscious effort to keep track of refactoring candidates, performance inefficiencies and other messes that'd otherwise languish under the rug and, maybe, just improving them before proceeding.

This is more of a problem in corporate IT than in the startup world. I have seen many projects in corporate IT that go way overboard to ensure their apps will scale.

But why? I am working on a major app right now that will have 300 total users. Ever. And yet the team wants to make the system scale to handle tens of thousands. Why?

The key is to know your audience. Is it truly realistic that the entire internet will become users? Or is it a smaller group? Scale accordingly.

I have a service, that brings me around $1300/month from which $700 is spent on App Engine hosting. It needs a rewrite, but profit do not justify it.

If you expect a similar situation - do the relevant premature optimization, so you can spend extra profit for bootstrapping :)

Assuming you could get the costs down to $200 a month by migrating elsewhere, over 12 months that is $6K. Is it worth it to rewrite it at that point?

I'm trying to convince myself with a similar argument :)

Have you taken a serious crack at profiling and benchmarking at all? The typical profile of a completely unoptimized application is that there is one enormous error that dominates the profile, which is often fixed by rewriting one single loop. Then, another enormous error that the first one was covering up will be revealed, similarly easy to fix. Then another fairly large error will be revealed but it isn't too hard to drop down to C for this routine. Then, the next one requires a significant rearchitecturing of the core bit, then aften a couple more repeats you hit the endless parade of dubious and expensive 5% improvements that really start compromising code clairity.

My point being that if you've never tried optimizing, it may be worth at least putting a couple of hours into it because progressing down the first couple of steps can be disproportionally beneficial. Also I know nothing about your personal situation so I'm also sort of throwing this out there in general.

Yes, i think i fixed the obvious bottlenecks. Unfortunately, i can't drop to C on App Engine.

"Premature optimization is the root of all evil (or at least most of it) in programming."

http://en.wikiquote.org/wiki/Donald_Knuth

Reply on news.ycombinator.com