Keeping things simple is challenging. It’s easy to fall in over-engineering, implementing bright technical features just because we think they will be needed in the future or falling in the latest and coolest hype, applying it in our system only to realize later that it wasn’t the best solution for our problem.
“People often optimize for the problems they want and not necessarily for the problems they have.”
— Lars Rosenquist https://redis.com/blog/5-microservices-misconceptions/
No matter our level of experience, adding accidental complexity to a system is all too common. To mitigate it, we must exercise caution, share ideas, learn from colleagues, and adhere to principles that prioritize simplicity.
Fortunately, we benefit from the wisdom of those who came before us, and we can build a good set of principles based on their guidance.
Delay decisions whenever possible
“A good architecture maximizes the number of decisions NOT made.”
— Robert C. Martin (Clean Architecture)
I take this principe as a good advise to focus on relevant problems at each stage of a project rather than solving everything at once.
A good strategy to incrementally build a system can help us delay some decisions, be focused on the current problems and to reduce the cognitive load as well, which is one of the main causes that adds accidental complexity.
Avoid premature optimization
“Be wary of premature optimization. It’s always a good idea to make sure an algorithm really is a bottleneck before investing your precious time trying to improve it.”
— Andrew Hunt and David Thomas (The Pragmatic Programmer)
Writing performant code that sacrifices readability without clear evidence of performance issues is not only wasteful but also accumulates technical debt in the form of poor maintainability.
Improving the performance of clean code is always easier than making performant code readable. Optimize your code only when it is necessary.
Follow the YAGNI principle
“Always implement things when you actually need them, never when you just foresee that you need them.”
— Ron Jeffries
YAGNI, You Ain’t Gonna Need It, as simple as that.
Implementing certain features just because we think they will be needed in the future and will save us work is not a valid reason to do so. Think about the consequences. What if the anticipated features, implemented ‘just in case’ are never requested or prove unnecessary? We risk ending up with unnecessary code. Worse yet, what if the requested features are the opposite to what we expect? This would necessitate a complete refactor.
Following the YAGNI principle ensures we avoid unnecessary complexity, making the system more adaptable to evolving requirements.
There are many other useful principles that could be added, but doing so might introduce unnecessary complexity to this set ;-)
As someone wise once said:
“Those are my principles, and if you don’t like them…well, I have others.”
— Groucho Marx
Top comments (0)