A common mistake I’ve seen is developers over-engineering new applications. While it can be partially caused by “ resume-driven design”, I feel it mostly comes from the assumption that the latest techniques seen online from large tech companies apply to everyone. Sure, the Googles and Facebooks of the world can be a great technical role model, but not every application has to be built like Netflix. I would even argue that a “next Netflix” shouldn’t be built initially like Netflix.
A city of 1,000 wouldn’t start with building airports, trains and highways even if it will become a city of 1 million. The same applies to software. Sure, consider the future of maximum scale, but new requirements and technologies will foil even the best plans. You just need to leave a way to evolve to the next stage.
A design pattern I see commonly abused in new projects is picking microservices over modular monolith. It’s hard to imagine a new application that should start its life as microservices. Even with a skilled team, the pressure to deliver the minimum viable product is strong enough such that there is a high risk of getting the worst of both worlds: a distributed monolith, or at best an over-designed and complex to debug system requiring dedicated DevOps engineers before you need them. In the beginning you should focus more on business requirements and value. I’ve seen this push to over-engineer many times – once, I was presented with a proposal to create a Kubernetes cluster for an application that otherwise ran with very little utilization on a single server with 1 vCPU and 4 GB memory.
Some rules of thumb that I have: