Draw a box around it. Given a large enough domain any solution will have certain flaws. If the domain is large enough without encountering the flaws, the solution is still useful. If you can enumerate the flaws, you can note them and come up ways to mitigate them once they become an issue.
Knowing a system’s limitations is important. You can disclaim them to all who will listen and do your job as a cautious engineer. Perfection in a system is often not economically viable or desirable given finite delivery of said system.
It is similar to the exceptional programmer who creates the indecipherable system that implements every feature that you could ever want. That’s actually an undesirable property when you’re only selling a handful of the features.
Implementing what you need and leaving affordance for what you expect might be a future problem/requirement is often a better approach. You don’t over complicate things off the bat (and drag out deliverables), but you leave yourself in a situation to make necessary changes without much trouble.
Knowing a system’s limitations is important. You can disclaim them to all who will listen and do your job as a cautious engineer. Perfection in a system is often not economically viable or desirable given finite delivery of said system.
It is similar to the exceptional programmer who creates the indecipherable system that implements every feature that you could ever want. That’s actually an undesirable property when you’re only selling a handful of the features.
Implementing what you need and leaving affordance for what you expect might be a future problem/requirement is often a better approach. You don’t over complicate things off the bat (and drag out deliverables), but you leave yourself in a situation to make necessary changes without much trouble.