Great tip Marko. In fact, I believe we can apply Pareto's principle in architecture too.
Providing an abstract layer for the 20% of things that will change more frequently is often good enough for a medium-sized project.
I'd say it's also difficult to abstract in advance. Most of the times you have a bunch of requirements and you try to fit them in a "generic context", just to figure out they don't any more a couple of months later (when they drastically change).
It's up to the developer to understand what needs to be abstracted (most common patterns like auth, routing, caching and stuff like that) and what may be left for a future refactoring (specific data or processes that are subject to change and not fit anymore).
What do you think, did you have any similar experience?
Great tip Marko. In fact, I believe we can apply Pareto's principle in architecture too.
Providing an abstract layer for the 20% of things that will change more frequently is often good enough for a medium-sized project.
I'd say it's also difficult to abstract in advance. Most of the times you have a bunch of requirements and you try to fit them in a "generic context", just to figure out they don't any more a couple of months later (when they drastically change).
It's up to the developer to understand what needs to be abstracted (most common patterns like auth, routing, caching and stuff like that) and what may be left for a future refactoring (specific data or processes that are subject to change and not fit anymore).
What do you think, did you have any similar experience?
Hi Giovanni, what an absolutely brilliant response! I agree 100%