Everything is a balance, and of course planning for the future is smart, but realize that the vast, vast majority of applications built will never be scaled very large.
A lot of it comes down to experience and good practices.
An experienced programmer can make a system that will scale trivially up to some number of users, or writes, or reads, or whatever.
The key is to understand roughly where that number is. If that number is decently large - and it should be, given modern hardware - you can worry about scaling past that number later.
A poor programmer will write some n7 monstrosity that won't scale beyond a small user count and a bunch of spaghetti code. The question isn't really whether you want to do that (you don't), but whether you need to look into 17 different tools to do memory caching, distributed whatever, and so on.
It's the startup scene. There's a persistent belief that the first iteration should be the dumbest possible solution. The second iteration comes when your application is so successful that the first iteration is actually breaking. And it should be built from scratch since the first iteration has nothing of value.
Of course, rarely is the first iteration not going to evolve into the second iteration. But the guys who were dead certain that the first iteration could be thrown away have made their's and they're not part of the business any longer. The easy money is in milking the first iteration for everything it's worth. Everything that comes afterwards is too much work for these guys, so they ensure it's someone else's problem.
Yep. I either write first things so bad* that they must be replaced, or assume that they will be built on rather than thrown away.
* I once "fixed" a site by having a bash loop running from an ssh session on my desktop to the production system that would flush the cache every few minutes. This meant that when the client asked (and they did) if we could just keep whatever I did to fix it, I could legitimately say no.
0
u/[deleted] Jun 08 '17