"Best Practices" aren't always the best
If you’ve been in the software industry for any length of time, you’ve definitely encountered the phrase “Best Practices.” It’s everywhere, in documentation, conference talks, code reviews, and architectural discussions. These guidelines represent the “supposedly” optimal way to implement services, follow conventions, or design systems. And honestly? Reading them isn’t a bad thing. It’s actually recommended.
Best practices give you valuable insight into how the creators of a tool or framework envisioned its use. They offer battle-tested approaches that have worked well in many situations. Think of them as the collective wisdom of the community, a starting point for understanding what “good” looks like.The wrong way to read the Best Practices, is to instantly consider them the best for your context or use case. I have seen many people fall in this trap, once they read that something is best practice, they stop thinking anymore and take it as a face value without even taking sometime and examining if their usecase fit this best practice or not.
For example, they read that microservices are a best practice, so they break apart a perfectly functioning monolith. They see that event-driven architecture is recommended, so they introduce unnecessary complexity to a simple CRUD application.
The problem isn’t the practices themselves, it’s the lack of judgment, context-free adoption of them.
Context Is Key
Engineering problems, especially those involving system architecture for business needs, don’t exist in a vacuum. They live within a web of constraints and requirements:
What are your actual performance requirements?
Who are your customers and how do they use your product?
What’s your team’s expertise and bandwidth?
What’s your budget and timeline?
How critical is this system to your business?
When you ignore these factors and architect in isolation, you risk solving someone else’s problem while completely missing your own. That scalable, fault-tolerant, highly-available system might be impressive, but was it what you needed? If all you needed was something simple and maintainable delivered quickly, you’ve failed miserably.
Best practices can be the best for some situations, maybe good for others, and doesn’t work for many. Use your brain, evaluate and choose the parts that works for your situation.
Before you decide to follow one, ask yourself:
Does this practice address a problem I actually have? Does it align with my constraints? Will the benefits outweigh the added complexity in my situation?