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.

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.