| Infrastructure wise, I'm absolutely guilty of this as well. I have found that there's a middle ground... You (probably) don't need the microservices and the complexity that comes with it, upfront. A monolith (and the simplicity in terms of deployment, logging, monitoring, etc. etc.) will probably do early on. However, you don't want to shoot yourself in the foot for when it turns out you do need those things. I try to write code in self-contained modules, with well defined boundaries, and glue it together in a monolith. If/when it needs to be split out into separate services, it becomes much easier. So, application/business logic code: keep the standards high, do shit properly. Glue code to keep it all together? Less important. You can rip that out later and move to different infrastructure with the same code. That's very generic advice, and I seem to always break my own rule on this at some point... but I find it's a better mentality for when shit just needs to get done. Doesn't help with tech choice in general though (and I'm often guilty of this as well...). |