[V-2]

Games couldn't rely on patches back in the day, because they used to be shipped in boxes, and providing patches was tricky. (The ease of providing updates may indeed incentivize releasing half-baked software nowadays).

I am less sure if those careless, youngest programmers endlessly scrolling Tik Tok videos are fervently dedicated to Martin Fowler's misled teachings.

And even less sure if the author summarizes them in a fair manner to begin with: "Many such organizations will build microservices even if their software domain complexity is not high and the software itself is not projected to scale that much. They will do it because their God told them to do it", he snarks.

If you go to Fowler's website [0], however (under "Are Microservices the Future?"), he's not dogmatically advocating for microservices: "Despite these positive experiences, however, we aren't arguing that we are certain that microservices are the future direction for software architectures [...] not enough time has passed for us to make a full judgement [...] There are certainly reasons why one might expect microservices to mature poorly [...] One reasonable argument we've heard is that you shouldn't start with a microservices architecture. Instead begin with a monolith, keep it modular, and split it into microservices once the monolith becomes a problem."

Doesn't really fit the image of a God commanding you to build microservices regardless of the domain complexity and other factors. Perhaps he's changed his tune since, I don't know. A quote would help.

On the other hand, observations such as that "from the usability perspective, the software must be user-friendly" , or "the role of software has become increasingly important, to the point where our world now heavily relies on it.", etc. are undeniably correct.

___

[0] https://martinfowler.com/articles/microservices.html