Changing considerations at different scales

Have you noticed that it's very easy to get started with certain languages and tools but when the project starts growing past a certain limit it all turns into an unmaintainable mess? After which you see new issues which are addressed by a different set of tools that are harder to get into initially but avoid some or many of the scaling pitfalls.

For example it was really easy to start programming in BASIC but the lack of tooling and features for structuring the code well put a very real practical limit on its ability to scale. With C on the other hand it was harder to get started but see all the things built with it. Nowadays one of such tradeoffs might be between running single containers in the cloud with e.g. AWS Fargate or self-installed Docker versus using a Kubernetes cluster.

This basic pattern repeats itself everywhere in programming and tech - and not just in two layers. There are undoubtedly several layers (infinite even perhaps?) of this everywhere.

How does this affect you on a practical level? First of all I would start off by being very wary of "easy to get started, immediate results, no coding required" tools by default. It's certain that this is only a rule of thumb and won't apply anywhere (there certainly are some tools and techniques which are both easy to get started with and do scale well).

What makes this such a hard problem to tackle is that one very often needs to learn the lessons with the simpler tools first to understand why some of the scaling features are required and potentially worth the time and monetary investment. Of course you also have to consider that not every project will need to scale up to Google scale so immediately starting to design an architecture for that will cause cost overruns and lead to very unnecessary non-lean over-engineering.

At this point I can't really provide further advice beyond keeping this consideration in mind when making tech decisions - and staying away from advertised silver bullets.

This effect also has a relation to another phenomenon in IT - namely reinventing the wheel with new technologies. As previously dominant language or framework starts getting mature and likely gathers many more features, it often also starts getting more complicated to use. This complexity combined with a few perceived faults in the language core give rise to a few new languages / frameworks that start with the premise of fixing the glaring problems and making it really easy to get started. Interest starts building up and soon it's noticed that some of the essential features are missing (that in the previous language were part of the base or had been added during maturing but are not technologically sexy highlights - and perhaps often relate to the larger scale management). The fix to this is often re-implementing the same basic features that often originate from the 60s and 70s - and often implemented by fresh juniors with lots of skill and enthusiasm but little experience and knowledge (thinking they're inventing something brand new).

Eventually (assuming the language / framework survives) the missing features get implemented in a sensible fashion, the latest new things starts nearing maturity - and the same cycle then starts again. Nowadays this cycle is present nowhere as visibly as in the JavaScript ecosystem.