// , βIt is not so important to be serious as it is to be serious about the important things. The monkey wears an expression of seriousness... but the monkey is serious because he itches."(No/No)
// , I recommend being careful not to optimize too closely. One of the best ways to avoid optimization is the ultimate flexibility: Keeping the option on the table to throw out the code, or well abstracted parts of it, and rewrite that code or product from scratch.
It's a little known "dark" pattern of Software Design, from the shadows of Agile, called "Sacrificial Architecture."
It came to mind when I read this in your post:
One thing I've learned: the prototype usually becomes the final code, so do it right the first time.
Should the prototype usually become the final code?
I've already run into a couple of projects that took the microservice path without really needing to β seriously slowing down their feature pipeline as a result. So a monolith is often a good sacrificial architecture, with microservices introduced later to gradually pull it apart.
// , I recommend being careful not to optimize too closely. One of the best ways to avoid optimization is the ultimate flexibility: Keeping the option on the table to throw out the code, or well abstracted parts of it, and rewrite that code or product from scratch.
It's a little known "dark" pattern of Software Design, from the shadows of Agile, called "Sacrificial Architecture."
It came to mind when I read this in your post:
Should the prototype usually become the final code?
martinfowler.com/bliki/Sacrificial...