Software development topics I've changed my mind on

13 yoe here, I don't find this true, in fact I find the opposite - storing data in binary (to minimise de/serialization overhead) and precomputing indices and relations in a simple K/V store easily and immediately annihilates best case performance you could get out of a typical relational DB. I don't work in FAANG so we don't get millions of reads/writes per second, but there's probably more use-cases like us than like FAANG.

Actually I recently discovered it is, it's just not what people think. Elegance is a function of the probability measure of how much someone likes your idea/solution/thing. There is a curve upon which people will think it is more or less elegant.

The problem is you can't actually see elegance from your own perspective. You might think it's elegant and it later turns out it's not to anyone else. And vice versa. It's like quantum physics: you have to observe it externally and your guess won't always be right. That doesn't mean it's not a metric. It just depends on multiple probabilistic measures.

It's important to gauge the elegance of things because in general, engineers will fight you harder the less elegant your idea is. It might be a better idea, despite its inelegance, but if you're working on a team, the team's acceptance of the idea is more important. (Unless you have total authority, in which case you can do whatever you want)

> Most projects (even inside of AWS!) don't need to "scale" and are damaged by pretending so

Actually it's the opposite: literally all projects need to scale. The problem, again, is perspective: the scale of the scaling varies.

If you have a physical business where you move goods around, you have to choose how to do that. You could buy a bike, or a car, or a truck, container ship, etc to move the goods. You might need just one or you might need many. Your business might increase or stay the same.

If you buy a container ship, probably you will never need to add another container ship again, as very few do that much business. But if you buy a bicycle, probably you will need to at least add more bicycles, if not change completely to a car or truck, or multiple.

If you use the smallest measure of compute on AWS, it's pretty much a guarantee it won't be sufficient for your entire workload. If you buy the biggest measure of compute, it's almost guaranteed it will be more than big enough. The scale of the scale matters.

Scale is therefore, again, a probability measure of whether your workload will match its container. If you could perfectly predict your workload and the capability of the container then this wouldn't be probabilistic.

But not only is your workload usually variable, so is the container. Bicycles/cars/trucks/container ships all can fail, so the scale of your workload may reach 0 at some point. The ability to scale dynamically is important in order to eventually deal with failure. Otherwise if your car died you could never get or rent another one, you'd have to sit there becoming an auto mechanic to get your business working again.

This is more obvious when you self-host. People take it for granted on AWS, where they don't realize that literally everything in AWS is scalable, and so tell themselves scalability doesn't matter... until it does. If we didn't have a way to scale bicycles/cars/trucks etc (by temporarily or permanently getting another one), the world would be much harder to do anything in.