[nitrix]

Delaying critical decisions in a project is crucial to making good decisions. They'll be made both by someone more informed (after learning all the complicated corner cases of the problem domain) and by a better developer (perhaps a future version of yourself).

Therefore, my advice is to pretend you're a junior developer and do things the most naive way possible. Allow things to stink, to repeat code and to support just what's needed, as if this was the absolute final complete state of the application. This may lead to eventual refactors and this is healthy as the focus will be on correcting existing problems instead of foreseen ones.

This is when you allow your senior knowledge and experience to do what's necessary to return to a state that's comfortable for a junior. It's counterintuitive, but at the scale of a large codebase, the occasional refactors ouweights the time wasted doing preventing design at ever layer. I actually have a similar stance about defensive programming and testing.

Since this might not be enough to appease your brain, keep in mind that abstractions are generalizations trying to encompass some common 80%+ of cases, but they're usually never perfect and leave behind edge cases with additional complexity. Unfortunately, composing abstractions is multiplicative. 80%*80%=64%. Do it enough and your whole application becomes unsupported edge cases, constrainted to fit within interfaces, functions and types not able to adequetly give you the results you want and, so, you go crazy down the rabbit hole, trying to desperately break it down into even more suitable abstractions, like that's going to help.

[skydhash]

It's the same "make it work; make it right; make it fast". The issue is that Scrum has emphasized the first one at the expanse of the other two. Minor changes over the lifetime of the project snowball into an inconsistent and complicated codebase. No time is given to reflect on the project and each module to refactor it into something sane every once in a while. It's all about velocity instead of maintainability, correctness, and performance. The craftsman in you will certainly react to that.