>The hardest lesson in the book is the chapter 11 "Plan to Throw One Away"
On the contrary, aren't factors like Microservices and all the constant prototyping at large companies encompass this? I feel in some ways they may have embraced the principle too much, to the point where prod doesn't have a properly stable solution to support while they are re-writing an experimetal "improvement".
Part of the problem is you don't necessarily understand the problem domain very well when you're starting out. There are plenty of examples of microservice architecture failures due to incorrectly dividing services- either causing too much internal communication for performance acceptance criteria, or struggling with service coordination when performing changes that impact multiple relationships.
You may well end up throwing away some or many of your early microservices as you grow and the company better understands what it wants to build.
Or, you can take another approach (which i have witnessed first hand), throw it all away and go back to a regular, well designed monolith and getting very significant performance improvements by doing things like SQL joins and transactions instead of putting events in a message queue and paying network traffic penalties.
On the contrary, aren't factors like Microservices and all the constant prototyping at large companies encompass this? I feel in some ways they may have embraced the principle too much, to the point where prod doesn't have a properly stable solution to support while they are re-writing an experimetal "improvement".