> When, not if, things break, there's a large benefit to having all of the logic contained to a few heavy-lifter classes that are contain bespoke logic and are

> When, not if, things break, there's a large benefit to having all of the logic contained to a few heavy-lifter classes that are contain bespoke logic and are fit-for-purpose. Things break in cycles. You'll have worked around a first wave and be happy that you didn't abstract your code too much as you can just fix one side of your logic very locally. It also means you didn't touch the other sides that were not directly affected, but probably needed a fix in a slightly different but overall similar way. So you'll see your code instances all break a way or another and fix them one by one instead of hardening a central piece where you could focus your testing efforts. Of course it's a topic that needs nuance, but if you identify a piece of code as duplicate, there will be no free lunch. Either you pay upfront the effort of abstracting, or you pay down the line the local fixes, but there's not one approach or the other that will be fundamentally wrong, I see it as a bet that pays off or not.