As developers and engineers we often try to build the perfect system that can handle every situation correctly. But building this kind of system takes a long time, it is usually involves a more complex architecture and at the end of the day you realize that you don't need this fancy design and complexity.
So how do you stop your "perfectionist you" but still maintaining a well designed system?
My two cents is that I usually map what the current challenges of the system are (e.g number of users, expected traffic, data modelling...) and if possible also to understand what is the next version, if the product roadmap is long enough. Then I am designing a system which overcome these challenges only. It has a clear downside, you can find yourself refactoring a lot but on the other hand you deliver quickly what is needed and can provide more value to the product.
Looking forward to hear your thoughts :)
Top comments (2)
Typically there are several ways to approach a problem, with varying levels of complexity. I try to go for the simplest approach, but with the added constraint that the approach I choose should (sufficiently easily) allow for all the future changes that I can readily envision. That means that I don't actively work towards supporting those potential changes, but I do avoid making choices that would hinder them.
I see what you mean, totally agree!