Good Problems to Have
Some scale problems should go unsolved. No. Most scale problems should go unsolved.
"To your pitchforks!", you shout. "Burn the heretic!"
Hear me out.
The thing is, most scale problems aren't problems at all. They are "problems". "Problems" are issues that will bring your software to its knees as soon as your customer base is multiplied x10,000. To its knees, i tell you!
Put that carriage back behind the horses. These "problems" we are so eager to fix are good problems to have. They aren't problems right now. They aren't problems we want to fix. They are problems we want to have.
"But we are engineers. All problems need solutions!"
True, but more pressing problems require solutions first. Consider the order of operations for building software.
The steps to good software
Back in the 80's, KentBeck defined good software creation as succinctly as i think it can be:
Make it work.
Make it right.
Make it fast.
Unfortunately for us overly ambitious engineers, most software will never make it past step 2.
This means that if you find yourself trying to make it fast before you make it right, you are not creating good software. You are creating a solution in search of a problem. This is bad practice, so we need a way to avoid wasting our time.
Identifying the good problems to have
The easiest way to avoid letting your development efforts get ahead of themselves is to learn to identify good problems to have and leave them alone.
Good problems are scalability issues that require beneficial changes to cause them. This scale is in the form of more users, media, data, etc. Here are some common fears along with some reasonable responses to the concern:
Q: "What if we have to upgrade to a bigger plan to send emails?"
A: "Good."
Q: "What if the user table gets too big and slows down the page loads?"
A: "That'd be perfect."
Q: "What if our users upload too many photos and we run out of space?"
A: "We should be so lucky!"
Now, of course, running out of storage space is terrifying. But the reality is these issues all require two ingredients: users and time. Neither of these come free. Or quickly.
Getting those users will require hard work, ingenuity and a little luck. So before we race to optimize prematurely, we consider if there are better ways to spend our time.
Spend your time wisely
The best reason to ignore scale is simple: you have better things to do.
Any product worth its salt has more missing features than its dev team can build. Given the supply/demand shortage of development time, it is critical to prioritize everything.
Robust optimization efforts are rarely justifiable. Instead, build the things your users desperately need. Improve your platform stability. Add the most requested features. Test some usability improvements. Increase your conversion rates.
Try causing the problem
For once, maybe you need to stop building solutions. Instead of solving a good problem to have, try causing one. Build the feature that triggers your explosive growth. Bring your software to its knees.
It will be the best damn thing you've ever done.
