
Does it scale? Who cares (2011) - ne01
https://jacquesmattheij.com/does-it-scale-who-cares
======
timewarrior
Couldn't agree with this article more.

I built the biggest social network to come out of India from 2006-2009. It was
like Twitter but over text messaging. At it's peak it had 50M+ users and sent
1B+ text messages in a day.

When I started, the app was on a single machine. I didn't know a lot about
databases and scaling. Didn't even know what database indexes are and what are
their benefits.

Just built the basic product over a weekend and launched. Timeline after that
whenever the web server exhausted all the JVM threads trying to serve
requests:

1\. 1 month - 20k users - learnt about indexes and created indexes.

2\. 3 months - 500k users - Realized MyISAM is a bad fit for mutable tables.
Converted the tables to InnoDB. Increased number of JVM threads to tomcat

3\. 9 months - 5M users - Realized that the default MySQL config is for a
desktop and allocates just 64MB RAM to the database. Setup the mysql configs.
2 application servers now.

4\. 18 months - 15M users - Tuned MySQL even more. Optimized JDBC connector to
cache MySQL prepared statements.

5\. 36 months - 45M users - Split database by having different tables on
different machines.

I had no idea or previous experience about any of these issues. However I
always had enough notice to fix issues. Worked really hard, learnt along the
way and was always able to find a way to scale the service.

I know of absolutely no service which failed because it couldn't scale. First
focus on building what people love. If people love your product, they will put
up with the growing pains (e.g. Twitter used to be down a lot!).

Because of my previous experience, I can now build and launch a highly
scalable service at launch. However the reason I do this is that it is faster
for me to do it - not because I am building it for scale.

Launch as soon as you can. Iterate as fast as you can. Time is the only
currency you have which can't be earned and only spent. Spend it wisely.

Edited: formatting

~~~
cyberferret
> I know of absolutely no service which failed because it couldn't scale.

I would say this is because of the simple fact of visibility and adoption.
You've probably never heard of these services probably because they ground to
a halt with a mere 1000 users, so they never got mainstream enough to be
recognised as a viable service. It is a bit like how no one remembers the
dozens of people who failed to achieve sustained powered flight before the
Wright brothers. Doesn't mean there weren't any, and scalability, technical or
planning issues killed those efforts before anyone knew of it.

Some 'scalability' issues are inherent to your initial design, and not just
the choice or configuration of your hardware/software platforms.

For instance, what if you were building a contact database of some sort. At
first, you may have things like 'Phone Number' and 'Email Address' as part of
the 'Person' database. Then, as your service gets popular, you notice people
asking for extra contact like Twitter handles, LinkedIn pages etc. So you
start adding _those_ to your Person table as extra columns.

Eventually, you realise that you should have though more about this at the
outset and have contact details stored in another data table altogether,
linked to a 'Contact Type' table and related back to the Person table. This
would have been mitigated at the start via better database design and catering
for eventualities that you might never have foreseen. Migrating the original
database to normalise it is a massive effort in its own right, and probably
will take _more_ time, cause more outage time, and cause more bugs in existing
code than designing for that eventuality in the first place.

Even if 99% of your users only ever enter Phone and Email contact details, the
second option, designed for scalability, will still handle that without a
sweat, and 'scaling' to meet additional demands later is merely a matter of
adding new contact types in the 'Contact Type' data table so that they become
an extra option for all your users.

I am willing to bet that 9 out of 10 'weekend projects' have had to be thrown
out completely and redeveloped from scratch when the number of users became
significant. Of those rebuilds, I would be interested to see some research
into how many users abandoned the said platform when (a) the original one
started to grind to a halt or constantly fell over with errors and (b) the new
platform came out with new features or a different UX that broke the 'look and
feel' of the original.

~~~
pbreit
You're refusing to learn from someone who lived it. I also know of zero
services which failed because they couldn't scale their technology. But I know
of 100s that failed because they couldn't get enough users or usage.

Your example about the DB tables is exactly the trap to avoid while you are
iterating rapidly to try and find product/market fit.

~~~
cyberferret
You are assuming that I haven't "lived it". Over the past 2 or 3 years, I have
built around 8 web apps. Some which got virtually no traction at all, and some
which have reached a happy medium of users and income. None which have reached
mega scale or millions of users (yet).

Some of the (real world) feedback I got from the web apps that failed to get
off the ground were due mainly to our customers complaining that:

* pages were taking too long to reload.

* not enough fields on a particular data table to store information in

* missing API

* pages that would refresh in entirety instead of just updating the changed portions

Most customers didn't stick around to wait for us to address or fix the issues
- there were plenty of other competitive products that fitted them better that
they could start using that same day.

A couple of those sites also got negative feedback on Reddit or HN because I
hosted the front end website on a $5 VPS server and when the site suffered the
inevitable 'hug of death' from posting to these sites, they immediately went
down due to inability to scale under the sudden deluge of visitors, and I
received uncomplimentary feedback on that (where people actually elected to
post feedback rather than just close the browser tab and completely forget and
move on from my app).

Yes, over thinking scaling and design is bad, but putting it aside as a
'totally not important now' factor is also just as bad, if not worse, in my
'lived it' experience.

~~~
timewarrior
It is great that you got a few which got traction out of 8 tries. This is an
incredible success rate.

Most people see much less success. The original suggestion is geared towards
first few tries that people make. Once they have made a few attempts, they
learn from it and naturally build more scalable products without spending
extra effort. You have already read my story about my first try which had a
very poor start. My subsequent efforts have scaled in that order without
needing a single rewrite.

However, if they spend too long procrastinating, worrying about and investing
in scale - they are wasting precious time which would be better spent finding
product market fit.

~~~
cyberferret
Thanks, and also thank you for not reading my posts the wrong way. I am in no
way having a go at you or refuting what you say. You've built something and
got it to a level that many of us can only dream of, and for that you have my
admiration and respect.

Like you, each subsequent app that I built contained the lessons learned from
the previous efforts - better front end frameworks, better data table
normalising, better hosting infrastructure etc.

Part of me always thinks back to the ones that _didn 't_ work, and I always
ask myself - _would_ they have worked if they had faster page refreshes, or
more flexible data entry? Perhaps if I had spent more time in the planning and
design before I launched them, they may not have sunk as quickly? Those 1000
users that time who came from my HN post and saw an 'Error 500' page - could a
fraction of them been the ones who would have signed up and made us profitable
if they didn't see the error page as their first introduction to my app??

For that reason alone, I am always skeptical of any post that promotes
'iterate often and fast' or 'fail quickly' rather than 'spend time on design
and a unique experience'...

~~~
timewarrior
It's all in good spirit of sharing and learning.

When you are thinking back, also consider the alternative where could you have
missed opportunities and product launches because of extra effort spent on
scaling upfront.

It's all good learning in the end. It's great to be in your situation. Keep at
it and you will see great success in future!

------
shadowmint
I care.

It's easy to brush off scaling concerns as not important, but I've had
personal experience where it's mattered, and if you want a high profile
example, look at twitter.

Yes, premature optimization is a bad thing, and so is over engineering; but
that's easy to say _if_ you have the experience to make the right initial
choices that mean you have a meaningful path forward _to scale_ when you do
need it.

For example, lets say you build a typical business app and push something out
quickly that doesn't say, log when it fails, or provide an auto-update
mechanism, or have any remote access. Now you have it deployed at 50 locations
and its 'not working' for some reason. Not only do you physically have to go
out to see whats wrong, you have to organize a reinstall at 50 locations. Bad
right? yes. It's very bad. (<\---- Personal experience)

Or, you do a similar ruby or python app when your domain is something that
involves bulk processing massive loads of data. It works fine and you have a
great 'platform' until you have 3 users, and then it starts to slow down for
everyone; and it turns out, you need a dedicated server for each customer
because doing your business logic in a slow language works when you only need
to do 10 items a second, not 10000. Bad right? yes. Very. Bad. (<\----
Personal experience)

It's not premature optimization to not pick stupid technology choices for your
domain, or ship prototypes.

...but sometimes you don't have someone on the team with the experience to
realize that, and the push from management is to just get it out, and not
worry about the details; but trust me, if you have someone who is sticking
their neck out and go, hey wait, this isn't going to scale...

Maybe you should listen to what they have to say, not quote platitudes.

Ecommerce is probably one of those things where the domain is well enough
known you _can_ get away with it; heck, just throw away all your rubbish and
use an off-the-shelf solution if you hit a problem; but I'm going to suggest
that the majority of people aren't building that sort of platform, because its
largely a solved problem.

~~~
Trundle
The article is about choosing a business idea where technical scale isn't
important. Twitter would fall under a "media play" which is what the author is
telling the reader not to do. They aren't saying "try to build twitter but
skimp on the tech" they're saying "don't try to build twitter, build something
where people pay you money to use it and you'll be raking in millions in
profit by the time technical scaling is an issue". Terrible example imo.

~~~
reledi
Twitter is not exempt. They focused on the product before scale. They were
regularly overloaded in the early days.

------
beefsack
Taking a completely blasé approach to efficiency is potentially as dangerous
as becoming hyper-focused on it.

Not all businesses become roaring successes, and those who achieve moderate
success often don't get the resources to fix deep-seated performance or
architectural issues (either via engineering and/or throwing hardware at it.)
Eventually these technical woes can completely halt momentum and I've seen it
even drown some businesses who just aren't able to dig theirselves out of the
hole the find themselves in.

People always seem to be arguing for extremes, but the most sensible approach
for most tends to be somewhere in the middle.

~~~
timewarrior
Agreed that completely blasé is pretty bad.

However in this case being blasé would mean, not working hard to scale when
you users are getting a bad experience. A basic stack these days
node.js+mongo, go+*sql can easily handle more than 100k users even with one of
the worst implementations. Most products don't reach that point!

~~~
beefsack
> A basic stack these days node.js+mongo, go+*sql can easily handle more than
> 100k users...

That is making some very large assumptions about application workload. For an
application which is purely a CRUD interface to a database, yes.

~~~
timewarrior
Agreed on this point.

Many a times there is heavy lifting - recommendations, machines learning etc.
However that is don't using specialized technologies in a non user facing
process and the results are then dumped into a DB available for a CRUD app.

I am hoping that products with such requirements will have some obvious tools
for such tasks (Hadoop, Hive etc) and they would find a way to scale such
processes with time.

So their stack might be go+*sql+Hadoop.

Can you please suggest some use-cases which don't fit the above pattern and
maybe we can brainstorm. Seems like a fun exercise!

------
salman89
I agree with the general premise of avoiding premature optimizations, but
designing systems that scale is important for several reasons:

\- Startups grow exponentially, if you're playing catchup as you're growing
you are focusing on keeping the lights on and hanging on for the ride.
Important for a growing company to focus on vision.

\- Software that scales in traffic is easier to scale in engineering effort.
For example, harder for a 100 engineers to work on a single monolith vs 10
services.

\- Service infrastructure cost is high on the list of cash burn. Scalable
systems are efficient, allow startups to live longer.

\- If the product you are selling directly correlates to computing power,
important to make sure you are selling something that can be done profitably.
For example, if you are selling video processing as a service, you absolutely
need to validate that you can do this at scale in a profitable manner.

I also don't agree with the premise that speed of development and scalable
systems are always in contention. After a certain point, scalable systems go
hand and hand with your ability to execute quickly.

~~~
Michielvv
In the projects that I was involved in in the past years, the ones that
decided to build a scalable infrastructure before gaining traction were
exactly those that were burning cash on infrastructure. There is just a
reasonable minimum of servers you need to run such an infrastructure and then
you need something similar as a staging environment to make sure it all works
together correctly.

That being said, there are of course choices that can be made early on that
will help you in case you need to scale at some time. Spending a bit of time
thinking through what would happen if you do need to split up and scale out
your system will help you avoid pitfalls such as relying too much on the local
filesystem being shared across pageviews.

In general I believe there is more benefit on spending time on performance
early on. (not caching, that is just postponing the problem) as it benefits
not just your ability to run on a single system for much longer, it will also
make life better for your users.

~~~
salman89
Scalable system does not imply needing many machines. There is no reason you
can't just deploy your entire system on a single host, but maintain the
ability to reconfigure exactly when needed.

But yes - its about finding the right balance.

------
devduderino
I care because it usually goes like this: Product manager > "Niche sass app
{x} will never need to support more than 10-20 users"

Two weeks after launch > "We have 10k users and counting, why didn't you
architect this for scale?"

Always assume you underestimated the scope of the project.

~~~
virmundi
I've literally been waffling back and forth between UUID and BigInt for the
last week. The reason for this is I need to handle eventually distributed
systems. Do I need UUIDs? Maybe not, but after much debt, I've decided that
the storage requirements of such an index in memory is worth the ability to
move from Postgres to Postgresql-xl.

~~~
qaq
The problem is not with memory problem is that after checkpoint postgres will
do full page writes for serial you will be touching way fewer pages compared
to UUID so write amplification for UUID vs bigint can be 60X+

~~~
virmundi
Can you go into a bit more detail? I've seen amplification referenced before.
My estimation is that the database will be pretty much read heavy. I will need
to split a given database across multiple instances.

~~~
qaq
[https://blog.2ndquadrant.com/on-the-impact-of-full-page-
writ...](https://blog.2ndquadrant.com/on-the-impact-of-full-page-writes/) this
is fairly detailed analysis of this issue

~~~
Dylan16807
How about simply using non-random UUIDs?

~~~
qaq
That would def. help

------
hopfog
I'm in the unfortunate position where this question actually matters from day
1. I learnt the hard way a few days ago when I hit the bottleneck (about
50-100 concurrent users) and I'm not sure how to proceed.

It's a multiplayer drawing site built with Node.js/socket.io. I'm already on
the biggest Heroku dyno my budget can allow and it's too big of a task to
rewrite the back end to support load balancing (and I wouldn't know where to
start). Bear in mind that this is a side-project I'm not making any money of.

I had a lot of new features planned but now I've put development on hold. It's
not fun to work on something you can't allow to get popular since it would
kill it.

~~~
spacetexas
Socket.io can't handle many connections you're right. I would use (universal)
Web Sockets (This is a good abstraction library, very easy to implement).

[https://github.com/primus/primus](https://github.com/primus/primus)

Maybe put it on a Digitalocean Server and just reference your Dyno's IP
address if possible.

~~~
hopfog
Thanks! Looks good so that's definitely something I should look more into.

------
dlwdlw
Flexibility vs efficiency. Agile vs high momentum.

As a rule of thumb, start-ups need to be more agile as they are mostly
exploring new territory, trying to create new value or re-scope valueless
things into valuable things.

Larger companies operate at a scale where minor efficiency improvements can
mean millions of dollars and thus require more people to do the same thing,
but better. Individualistic thinking on new directions to go is not needed nor
appreciated.

Of course there are excepttions. The question boils down to whether or not the
ladder is on the right walk before charging up it.

In rare circumstances you can do both. Either the problem is trivial, or the
problem becomes trivial because you have a super expert. 10x programmers who
habitually write efficient code without needing to think too much have more
bandwidth for things like strategy and direction. The car they drive is both
more agile, accelerates faster, has a higher max speed, etc...but even this
can't move mountains. The problem an individual can solve, no matter the level
of genius, is still small in scope conpared to the power of movements and
collective action and intention.

The most poweful skill is to seed these movements and direct them.

Abstractly, this is what VCs look for in founders and also a reason why very
smart and technical people feel short-changed that they are not appreciated
for their 10x skills. (Making 500k instead of millions/billions) They may have
10x skills, but there are whole orders of magnitude they can be blind to.

------
didibus
The reason scale isn't so important today is because most DBs can actually
scale vertically to really high numbers. The tipping point is high enough that
if you have this problem, you probably can also afford to fix it.

What matters though is performance and availability. No matter what scale you
work at, you can't be slow, that will drive people away. You also can't be
unavailable. This means that you might have to handle traffic spikes.

Depending on your offering, you probably also want to be secure and reliable.
Losing customer data or leaking it will drive customers away too.

So, I'd mostly agree, in 2016, scale isn't a big problem. Better to focus on
functionality, performance, security, reliability and availability. These
things will impact all your customers, even when you only have one. They'll
also be much harder to fix.

Where scale matters is at big companies. When you already have a lot of
customers, you’re first version of any new feature or product must already be
at scale. Amazon couldn't have launched a non scalable prime now, or echo.
Google can't launch a non scalable chat service, etc.

~~~
hamburglar
> Where scale matters is at big companies. When you already have a lot of
> customers, you’re first version of any new feature or product must already
> be at scale. Amazon couldn't have launched a non scalable prime now, or
> echo. Google can't launch a non scalable chat service, etc.

This is the point I was going to make. When you are designing the very
platforms on which all these "does it scale? who cares" startups are going to
be built, you do not have the luxury of having that attitude. Definitely don't
take that mindset into an interview at google or amazon. :)

I do agree with the OP's sentiment for startup projects in general. I have had
the experience of worrying about scale too early and over-engineering a system
which never had more than a few dozen users, and the opposite experience of
tossing something together that wouldn't scale and then going through the
hairy scrambling at every order of magnitude of scale through tens of millions
of users. The latter was definitely a better strategy.

------
addicted
Healthcare.gov was a site that failed and suffered due to scaling issues.

However, it was an anomaly because unlike a product someone this article is
intended towards would be building, that site had an immediate audience of
millions of users from the get go.

Also, the fact that it took a few weeks to be rewritten to handle the load at
which point it became extremely successful, strengthens the original article's
point.

By the time scalability becomes a problem, you will have enough resources to
tackle the scalability problem.

~~~
user5994461
This is not an anomaly.

It's the norm for all government projects, and most projects started in
established companies that already have millions of users.

To be working in these domains, the "doesn't need to scale" mentality" is very
inappropriate and I find it to be doing a lot of damages.

The guys at healthcare handled most the scaling problems, accounting for the
means at their disposal and the time frame they had, judging by what was
published in the news. That it took a few weeks to smooth showed that they
handled scaling beforehand. A launch from 10 users to 10 million is always a
bit bumpy for the initial weeks.

------
Jach
No one else bothered by "End-to-end tracking of customers" as the primary
concern? Ok then.

On the subject of scaling, I think it's good to have an idea in your head
about a path to scalability. One server, using PHP and MySQL? Ok. Just be
aware you might have to load balance either or both the server and DB in the
future, and that's assuming you've gotten the low hanging fruit of making them
faster on their own. But as this thread's top comment illustrates, learning
that stuff on the fly isn't too hard. So maybe it's better to make sure you're
going with technology you sort of know has had big successes elsewhere (like
Java, PHP, or MySQL) and even if you're not quite sure how you might scale it
beyond the defaults you know others have solved that problem and you can learn
later if/when needed.

------
tyingq
He makes the valid point that performance for each individual user, like page
load time, does matter. Just that building for an audience size you don't yet
have is mostly wasted time.

Seems reasonable. I wonder, though, if PHP feels like an anchor to the average
Facebook developer. I realize they architected around it, but it must have
some effect on recruiting, retention, etc. I use PHP myself, and don't hate
it, but the stigma is there.

~~~
toomuchtodo
Any stigma should be prioritizing tech over the business. Your business exists
to turn a profit, stack be damned.

~~~
tyingq
That works to motivate some employees, assuming their comp is relative to your
business success. Facebook has been able to do that for some time, but there's
probably a plateau or two in their future.

------
sbuttgereit
The overall premise of the blog is exactly correct; though I would say some
areas you probably need to consider more than others.

Spending a lot of time figuring out what exact microservice/sharding/etc
strategy you need to serve a zillion visits a day and building it before
you've even got customer/visitor one is overkill out of the gate. But that
shouldn't mean you shouldn't think about how you'll scale over the short term
or medium term at all.

When I approach scaling, I'll tend to spend much more time on the data
retention strategy than anything else: databases (or other stores), being
stateful, means that it's a harder problem to deal with later than earlier as
compared to the stateless parts of the system. Even so, I'm typically not
developing the data services for the Unicorn I wish the client will become,
I'm just putting a lot more thought into optimizing the data services I am
building so it won't hit the breaking point as early as it might if I were
designing for functionality alone. I do expect there to be a breaking point
and a need to change direction at some point in these early stage designs. But
in that short to medium term period, the simpler designs are regularly easier
to maintain than the fully "scalable" approaches that might be tried
otherwise, and rarely do those companies ever need anything more.

------
uptownfunk
I like the overall idea here. Focus on building something quality first then
worry about scaling later. Most servers can handle a decent amount of traffic.
Seems like common sense to me. I guess some people can get too hung up on
engineering to make their site scale before actually deploying or innovating
on the product. Wonder if people have encountered this in the workplace
before?

~~~
CodeWriter23
I think the point is to make something that makes money first, then use the
money to make something quality.

------
innocentoldguy
I agree with this article; however, there are considerations that can be made
early on, to ensure an easy path for future scalability, that don't waste any
time or money during the project's nascency. For example, if I know I want my
app to scale at some point in the future, I may opt to build it in Elixir, or
I may choose to use a Riak cluster rather than of MySQL.

------
xyzzy4
Ok but please don't do things like using nested array searches with bad
runtime when you can use hashmaps instead. I hate seeing code or using
programs that are extremely unoptimized.

~~~
tyingq
That seems to be the real story behind most "We switched from stack X to stack
Y and gained an Z-fold increase in performance" stories. They tend to leave
out the "and we also fixed some generically bad things we found when porting".

------
nomercy400
Once worked at a startup where we expected 'some activity' in our webshop at
product launch, and didn't think about scaling for that. Well, some activity
turned out to be 450mbit/s for five hours, which our unscalable
application/webshop didn't handle very well. It became overloaded in the first
minute, and took us more than an hour to get remote access again. It's one of
those things we did better for our next big event (major sharding, basically
replicated the application 32 times of the largest VM instance we could get.
It was needed and it survived).

------
the_arun
I agree with this article only for launching new products. But if you already
have a product which is serving millions of customers, you better worry about
scale while you change anything.

------
partycoder
While a point the article tries to make (fix your leaky funnel before
acquiring users) is true, I disagree with the article. If your application is
converting well, scalability problems are not acceptable.

I have seen applications that convert very well, but were limited by
scalability problems. That meant that the business had to hold on on marketing
and user acquisition, missed their financial targets, and that cascaded into
breaching contracts. The phrase that nobody wants to hear in that situation is
"who cares about scalability".

Now, if you did not have a lot of problems scaling in your particular case,
that just means it was not an obstacle for you. e.g: you had good intuition
around performance/scalability, or the problem was coincidentally a good fit
for your technological choices.

Unfortunately not everyone has a good intuition about scalability, not
everyone is risk averse and not everyone is good at picking a good technology
for their use case. So I disagree with this article in the sense that it is
not in the best interest of a random reader to not care about scalability.

------
iveqy
Having working on an app that we just throwed more hardware at, to the point
where the azure subscription cost could be lowered by my whole anually salary,
by 3 months work of optimization.

I believe performance does matter. We where a 4 person team and could have
added a fifth if we had a cheaper design.

------
therealdrag0
I started working at a company 6 months ago, and in that time I've fixed a
half dozen performance problems.

Some of them didn't matter THAT much, but some of them did. My team manages an
authentication -service. Some of the calls were averaging hundreds of ms which
added terrible overhead to other services' calls. In other places had CICD
builds running tests twice, logs logging twice, inefficient algorithms, single
HTTP transactions making dozens of DB calls. You name it.

Some of these were simple things that if you stopped to smell the roses you
could notice and fix.

Let's all be boy scouts and make code better while we're in it :)

------
janwillemb
In general: don't fix a non-existing problem. You don't know beforehand what
the problems of the future look like. Fancy technology X of today is technical
debt in 10 years. So do invest in solving technical debt along the way in
products you keep.

------
mannykannot
There is a similar argument with regard to making code reusable. I have seen
inordinately complex code come from a desire to make it reusable, even if the
prospects for it being reused were slim to nonexistent.

------
shoefly
Evolution is a beautiful thing.

I once worked for a monolith who decided to invent a new way of programming.
They built something massive and ready to scale even larger. And then they
discovered no one wanted the product.

------
andromeda__
Fundamentally disagree with the ethos of this article. What about ambition?
What happened to that?

> You won’t make the cover of Time Magazine and you won’t be ordering a
> private jet but that Ferrari is a definite possibility, if that’s the thing
> you are hurting for. (college education for your kids is probably a better
> idea ;) ).

I'd like to be on the cover of fortune or as Russ Hanneman might say, "I wanna
make a fuckton of money all at once".

I don't see any problem with being ambitious or wanting that private jet.

------
amelius
A better title would be: scalability is a luxury problem.

------
shanecleveland
Came across a service last week with a free trial and paid plan. How to
upgrade? Contact by email! Why spend time and resources on a payment process
if you don't have any paying customers yet?

Obviously not right for everyone, and I'm not saying it doesn't have its own
challenges, but the core product deserves the most attention early on.

------
seajones
I do agree, but being at the "we need to scale up asap" stage atm makes it
harder to. There's a balance to be struck. Maybe about approach of "who cares"
with the POC, MVP etc stages, then keep it more and more in mind at each stage
after that would be best.

------
tianlins
It really depends the type of growth. Organic growth is driven by the quality
of product therefore scaling issue comes later. But most venture-backed
startup services such as O2O need quickly dominate market by throwing cash to
get users so scaling is an issue from day one.

------
debt
i concur. it's fun to dream, but sadly, statistically most of us will never
have to worry about scaling! so save yourself the energy and don't worry about
it.

------
Vkkan2016
IMHO until you hit scalability issue don't try to spend your time and money
there yet

------
ninjakeyboard
I agree BUT it's not that hard to ensure your app scales. It's more about
using appropriate tools for the job.

------
namanyayg
Can we have (2011) in the title?

------
cabaalis
I liked the article and agree with its premise. But as a side question, why do
developers use so many parenthetical expressions?

Those ideas (like this one, which happens to add nothing) are often either
throwaway statements (like this one) or are by themselves complete thoughts
that should be a separate sentence. (I see this so often in posts written by
devs.)

~~~
soneca
Nice writing :)

I would blame it as commenting habit. Need to explain everything twice. "What
if the reader doesnt understand _exactly_ what I mean?"

~~~
2muchcoffeeman
So use a separate sentence or formulate your ideas more clearly? I see this so
often when developers write. From tutorials to official documentation etc.

Extra words where a simpler sentence would have sufficed, poor structuring of
ideas, not splitting text into appropriate paragraphs and sentences. I always
feel dumb until I figure out what was trying to be said and then you realise
just how poor the writing is.

~~~
camel_Snake
You should write a post on the parallels between legible code/english.

