An enthusiastic YES to this from @henrikjernevad:
https://mastodon.social/@henrikjernevad/112160702537117343
I recognize every single one of those examples from the post’s intro. And I recognize the pattern: developers imitating tech giants on small projects where those giant-scale approaches make no sense at all.
I like Henrik’s question: does it scale •down•? Does it scale down to the size of our actual team, our actual project?
1/
A lot of my own software work has been for very small companies: arts nonprofits, early startups, one-person bootstraps, community orgs that are and always will be small.
These orgs have problems that are very, very different from the problems that, say, Google has. There’s no sense in them inheriting the miserable tech tradeoffs a giant corp faces! Enjoy being small! Do it the simple way! Stay flexible!
2/
You’d think that “it has to scale to 100 million users!!” is a pressure that comes from over-eager owners counting on massive growth, but in my experience, misapplying the patterns of tech giants to tiny orgs is a mistake that usually comes from us developers. We like shiny things. We over-scale either because the tech seems cool, or just because we feel like we’re •supposed• to.
But: What problem does the tool solve? Do we have that problem?
3/
One of the problems that @henrikjernevad doesn’t get into in the blog post is that scalable code, like performant code, tends to be •brittle•: larger, more complex, more difficult to modify.
If you have only a handful of users, you have the incredible luxury of being able to write non-performant, non-scalable code that allows for •revision•. You can fiddle with design! You can learn from your mistakes and adjust quickly! It’s an •incredible• competitive advantage.
4/
It sucks being Google: if you so much as fart, you have a million users overnight. The second your product goes out the door, it’s half-calcified. Human-centered iterative design process? Forget about it!
Apple generally solves this by incubating things in secret forever. Google and Amazon solve it by training users to live with pervasive UX problems. If you’re huge, there is no good answer.
If you’re small, enjoy your incredible leg up: you have a chance to build good things fast!
5/
If you are tiny and looking to stay tiny…you have my heartfelt blessing.
If you are tiny and looking to grow, keep it simple, focus on building something great, and hope that one day you are •lucky• enough to have so many users that you need to rearchitect for scalability.
Honestly, more often than not, that moment of needing to rearchitect for scalability is a sign of •success•: somebody chose the tools that were appropriate to being small, and they succeeded.
/end
This from @henrikjernevad, 100%:
https://mastodon.social/@henrikjernevad/112939338754671394
If you don’t have a clear sense of what you need to •test• to ensure that your scalability plan works under your own real-world conditions, that’s a sign that you are making it up and don’t actually need that scalability yet/ever.
Consider: the cost of building supposedly scalable code and getting it wrong and having to redo it when scale actually hits is generally •higher• than the cost of keeping it simple and then having to redo it when scale hits.
@inthehands Complexity is easier to add than remove. Simplicity lets you see more clearly where complexity can be added. I feel like most scalability concerns are wishful thinking and premature optimization, more YAGNI than reality. Working with a lot of legacy code, some of the most irritating and complex code is leftover optimizations for limitations that no longer exist. Add Google-scale optimizations when you have Google-scale money and Google-scale problems