I love this. Over the last months (if not years) I really focused more and more on managing complexity. (I think I already shared John Ousterhout’s great 'A Philosophy Of Software Design' book here... which is all about understanding, managing and anticipating software complexity)

At the end of the day, it always comes down to pragmatism.

A splendid design which does not solve a problem we have is useless, and usually brings unneeded complexity which makes updating/maintaining/modifying the system more difficult, costly and error-prone.

I recently read again Tef’s blog post about code: Write code that’s easy to delete, and easy to debug too and Write code that is easy to delete, not easy to extend.

Complex designs often become necessary.... after some time. But we should always start with something simple (e.g. a small monolith) and only split it (or add another part alongside rather than extending it) when we have good reasons to do so, and when we already have the tools in place to be able to use it and test it easily (which is usually not the case if we want the full microservice experience from the beginning... because we have everything else to build too)

This makes a great context to remind people about Gall’s Law:

"A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work." - John Gall