The counterpoint here is that it's oftentimes hard or impossible to know what exactly you'll eventually be building before you build it, especially with somethi

The counterpoint here is that it's oftentimes hard or impossible to know what exactly you'll eventually be building before you build it, especially with something like a startup where experimentation until you get product-market fit is the norm, or a project which has an expected life of multiple years/decade(s). If you sit there pre-planning every last detail of something, that usually means you end up making a lot of assumptions that eventually turn out to be false. It can be a sad day if one day realize you that your entire code is structured towards doing stuff one way, and then your requirements are the opposite. This is true even when you think you've thought of every possible option - life has a way of being surprising. Specifically abstraction is a tool to be used strategically, not a blunt instrument to bash your code with. Rushing into abstraction can kill a good codebase because it's difficult to refactor code to extricate yourself from a bad abstraction. Also a lot of abstractions come at a cost, e.g. the build takes longer, there is more boilerplate to get a simple thing done, you need multiple servers and orchestration to run the app, etc etc I'm finding that the thing to do instead is to build things open to change and extension, but initially allow some inefficiency / repetition / stupidity in favor of less complexity. You build in complexity as you need it. Examples: Don't start with the fanciest logging stuff, do use a uniform function call that is easy to find / replace later on. Don't start with containers or even separate repositories, but do keep logic between areas of code cleanly separated such that you can pull them apart easily later, etc.