3 ms·
One of the hardest parts of software architecture, in my mind, is striking the right balance between YAGNI and future-proof abstractions. Abstract everything to
by elric 6y ago
One of the hardest parts of software architecture, in my mind, is striking the right balance between YAGNI and future-proof abstractions. Abstract everything to death, and you end up with what OP is describing. Abstract too little, and your codebase becomes rigid, hard to test, and so riddled with details that new developers will fail to see the bigger picture.
- ozim 6y agoI would say problem is that people worship DRY like it is some kind of golden rule. Where KISS, YAGNI and "premature optimization" are left in the corner crying. Pointing out DRY is easy and during code review all devs know that someone will be nagging about it. Where if you build an abstraction even if not needed or plain wrong there is a high chance that no one will have any comments, because reviewers will go with low hanging fruit and point out DRY violations. It will be more work to find out how abstraction work and point out its weakness, and don't ever even try to propose that code duplication might be a better solution than broken abstraction. Whenever I can, I try to push rule of 3 for dealing with duplicated code. Unless something is used 3 times it still is not a duplication.
- oftenwrong 6y agoToo little abstraction is rarely a problem. It's easy to change something simple and straightforward. When a bunch of stuff depends on a bad abstraction, it's both hard to change, and hard to keep.