For the most part, I agree with a lot of this, but there were a couple points I raised an eyebrow on.
> There is no pride in managing or understanding complexity
To the point that intentionally creating complexity or allowing it to continue to exist where it can be simplified, I agree - but some systems are necessarily complex and having pride in understanding and managing them is a good thing. If no one had pride in this, why would anyone care about the things that aren't simple - or bother to train the ability to simplify the complex in the first place!
> Micro-services require justification
I used to believe this, but have changed my mind on it. Micro-services are great in the current CS ecosystem (at least in the US) because they allow smaller parts of the whole to be more easily refactored when you find your development team with none of the people that were present when design decisions were made and a major feature needs to change.
It's an unpleasant situation to be in, and one that you ideally want to avoid happening, but is common enough that preparing for it in your application landscape is reasonable.
you don't need microservices to accomplish that - a library with a well designed public api and a language that lets you enforce private functions/methods are good enough,
> There is no pride in managing or understanding complexity
To the point that intentionally creating complexity or allowing it to continue to exist where it can be simplified, I agree - but some systems are necessarily complex and having pride in understanding and managing them is a good thing. If no one had pride in this, why would anyone care about the things that aren't simple - or bother to train the ability to simplify the complex in the first place!
> Micro-services require justification
I used to believe this, but have changed my mind on it. Micro-services are great in the current CS ecosystem (at least in the US) because they allow smaller parts of the whole to be more easily refactored when you find your development team with none of the people that were present when design decisions were made and a major feature needs to change.
It's an unpleasant situation to be in, and one that you ideally want to avoid happening, but is common enough that preparing for it in your application landscape is reasonable.