

Startups and The Problem Of Premature Scalaculation - coderdude
http://onstartups.com/tabid/3339/bid/3055/Startups-and-The-Problem-Of-Premature-Scalaculation.aspx

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

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

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

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

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

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

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

"Scalaculation" is a weird word.

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

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

------
mike_esspe
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 :)

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

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

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

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

