Additionally, as I get older, I find the sentiment of "we're not trying to build a perfect system here" is less about "let's just go fast vroooom" and more akin to saying "I've been humbled before by thinking I had the perfect mental model of the universe before a single user touched the product."
Then engineers are on the hook because they run into those constraints while building and everyone always blames „those lazy software developers” ;)
At work we agreed that some use cases are very niche. These have guards in place to log an alerted-upon marker + return HTTP/500. They have not tripped for years by customers. So, it's fine to not support some rare cases and to deliberately leave known gaps in some contexts. As long as you don't close these paths forward if you need them.
On the other hand, we have contexts like our PostgreSQL instances. Those have a very well defined scope and rooting out all known problems has been the right choice. Most issues we have ignored in that scope have bitten us in the butt sooner rather than later. Very hard in some cases, I may add.
Realizing this about a domain is very important.
No. It is cutting unused features to make a manageable product.
* "That won't work on GCC 5.5." We don't support GCC 5.5, or any compiler which wasn't shipped this decade.
* "What about FreeBSD?" What about it? We only have Linux servers
* "This only works on systemd." Good, we're a systemd shop.
In online discussions people always blame „lazy developers „ like there would be no product owners, testers, business analysts, scrum masters etc.
In my space this is usually something like, "X won't work on POSIX make", being a reason not to add X to the build system. Well, it works on Ninja, and on GNU make, so it just won't work on POSIX make and the handful of deployments still using POSIX make just won't use X.
I'm ok with this as long as dropped requirements are documented and nobody wakes you up at night when those edge cases show up in production. Also, when the next feature needs to build on top of those dropped edge cases, you are given enough resources to redo the previous solution.