because scaling
Part of a series of posts that discuss justifications for spending more time on a specific piece of code, rather than continuing onward.
The scaling justification goes something like this:
As soon as people get a taste of what we’re building we’re going to have to handle SO much traffic! We’d better think about how we’re going to scale this NOW so that when we need to we’ll be ready.
When does the desire to scale mislead us?
This is one of the most common mistakes I’ve run into, especially when working on teams that were building new products that didn’t already have an established customer base. It’s basically an illusion of grandeur behind a very thin veil. The concern is always that sales and growth will go so fast that we won’t be able to handle the traffic and as a result we’ll go out of business. Look — if your business ever goes out of business for having too many customers then you’re not looking at the problem in the right way — something about your business model is broken.
- The vast majority of systems built barely need to scale beyond their initial design, if at all
- Those that do scale quickly are not only extremely rare, but by virtue of their enormous growth they tend to either attract the revenue or the investment necessary for them to scale, even if it is painful
- The most common reason for new products to fail is a lack of customers, not a flood — i.e. a complete lack of demand
When does scaling help us?
Scaling is primarily a matter of working the problem with people who have been down the road before — so the #1 rule in scaling is don’t do it until it’s necessary, then simply get the right people on the problem, and don’t worry so much. The most common scaling challenges have been solved through pay-for-usage platforms and software-defined networking, storage, and compute resources. There’s no shortage of blog posts, documentation, and tooling to scale far beyond what the vast majority of engineers is ever likely to need.
