BlackWindBooks.com | Newsletter! | risingthumb.xyz | achtung.risingthumb.xyz | github.com/RisingThumb | site map

risingthumb.xyz Why don't you wash up occasionally like any other human being?

YAGNI and Scalability

Firstly, YAGNI is an acronym meaning "You aren't gonna need it". It's often used in reference to software development, commonly around premature optimisation, and to a lesser degree around when to use some gang of 4 design patterns.

But I don't hear YAGNI get mentioned much with relation to scalability. I've heard of plenty of businesses adopting the latest and "greatest" cloud tooling... AWS with microservices and so on. Quite frankly, even having a dedicated DB server is often overkill for plenty of these businesses, as they will never reach the point that a basic file-based SQLite DB will exceed their use case.

The consequences of this, is often a bigger bill, which for a small business or if you're working in an area with slim profit margins to begin with, can be a silent killer, and that the tech stack becomes over-complicated and starts to drown in complexity. The consequence of complexity, is your developers need to be better trained. Considering most companies want full stack software developers instead of exclusively frontend or backend software developers or sysadmins... as it requires more knowledge, it should be expected that there'll be gaps and errors as a result of it.

My opinion here is to just go with a bog-standard simple CRUD system on a monolithic server. When you hit scalability constraints you can expand according to them. A database is the easiest example of this, as most use SQL languages where switching isn't too hard.

=> An appropriate use for SQLite is most websites

But, this is where I come back to YAGNI. Speaking anecdotally, I've observed a lot of the fervent supporters of YAGNI haven't thought it through to apply it to scalability problems.

Don't take Google-scaled approaches to software if you aren't at that Google scale. You'll just get a bigger bill for hosting it and struggle to maintain it.

P.S. After posting this blog post, UltramarineWeather on the Agora Road forum directed me to a paper "Scalability! But at what COST?". This paper presents how the naive approach to a problem that has poor performance can sometimes scale better than a performance-optimised solution to the problem. To me, this presents how important it is to know whether what you're working on needs to be scalable or not. If you don't know and it's performance-critical, you may as well implement it both ways and measure. If it's not performance-critical, you can deal with the problems as they arise.

=> "Scalability! But at what COST?" paper.
=> UltramarineWeather's website

Articles from blogs I follow around the net

Quickie: 1957 Ferrari 625 TRC Spider

Yum. This article was originally published at: https://andrei.xyz/quickies/1957-ferrari-625-trc-spider/

via andrei.xyz June 12, 2025

thecozycat 😂 I never think about the consequence of how much wo...

I never think about the consequence of how much work it's going to be when I change directions on something lol

via thecozycat June 12, 2025

World of Warcraft players are faggots

Now that I got your attention with this “highly offensive” article title, and before you call me out for my very own faggotry, let me say that if you got offended of six simple words, I hope you’ll go die for Ukraine in a ditch somewhere, and in the next …

via sizeof(cat) June 11, 2025

Generated by openring