I am super inspired by Pieter. At the same time, I'm also not a believer of a one size fits all approach. A lot of Pieter's work these days is built around remote working communities. His first ideas when he was doing 12 months, 12 startups were very singular in focus. Nothing wrong with that at all. At the same time, Pieter's approach has not been used across a broad range of products in terms of product complexity.…
i mean, facebook started as a very light php app and then they just built layer upon layer upon layer on top of it until they basically now have their own fork of php.
Also I would be very surprised if there is any code left form the early days. FB was (to my knowledge) rebuild "form scratch" several times during it's life-time.
Also I don't think one could build a website with PHP and SQLite and scale this out unmodified to millions of concurrent users for example.
But most websites don't have millions of concurrent users, and it's true that some very "basic" tech is more than enough to server one's users well in the majority of cases.
The horrible amounts of over-engineering one can see "everywhere" are imho a result of two issues: People building stuff and using tech they don't actually need! Most people don't have the problems Google or FB have for example. Still people are running static websites on Kubernetes nowadays, and things like that. (You know, in case you need to quickly scale things out this makes perfect sense, doesn't it? ;-)).
IMHO one of the main points of good engineering is to choose the right tool for the job. This means that in 99% of the cases you're actually perfectly fine with even a "bare metal PHP / MySQL" stack (or similar). Especially if you're just trying get something up the ground.
On the other hand's side a good engineer should know upfront when this won't lead to the desired result. As an engineer you should know all of your tools. The simple day to day ones but also the complex and advanced ones — you need to choose wisely which to use when. If you don't think about all of the possible design space, and all the pros & cons of going some direction, you're otherwise just a guy with a hammer; and not an engineer…
So it makes imho a big difference whether it is an informed choice to use "low tech" or just the result of "I don't know better". No matter the (first) outcome may look quite similar.
In the first case there is a chance that the people that did that will be able to "scale shit out" or add all kinds of features in a clean way. In the second case one can expect that the people that "just had an hammer" will create in the future the usual "layers and layers of mess" all over the place when tasked to extend or scale their system, as they just don't know better.
As a bottom line: Software engineering is hard, very hard. To arrive at a simple but correct solution is almost an art and requires the most skilled and knowledgeable engineers money can buy. It was a genius btw who insisted on things being as simple as possible, but not simpler. Coming up with "a simple solution" (ignoring half of the problem) or "killing flies with Bazookas" is trivial, everybody can do that. But that's not proper engineering, imho.