I’m not sure I like this because you will always be wrong in what ways the code needs to be flexible. The most flexible code is soaking WET where each component is self-contained with no shared dependencies, no abstractions, and can be thrown out or rewritten with absolutely no possibility of it affecting any other parts of the service.
Devs hate writing this code, every fiber of your being recoils at the thought of just copy/pasting everywhere, ignoring anything that seems like a pattern, and having several identical API endpoints just to keep everything wet. But you will never be so productive in the face of changing requirements.
> But you will never be so productive in the face of changing requirements.
I couldn't disagree more. Failing to represent each piece of knowledge from the requirements in a single authoritative place means that simple requirements changes often have massive costs, as instead of one change to the place where the changed element is unambiguously represented, you need to change all the distributed locations where it is (often opaquely/implicitly) embedded in logic.
The problem is when DRY gets misinterpreted as “never write generally similar-looking code” rather than “every piece of knowledge must have a single, unambiguous, authoritative representation within a system.”
Devs hate writing this code, every fiber of your being recoils at the thought of just copy/pasting everywhere, ignoring anything that seems like a pattern, and having several identical API endpoints just to keep everything wet. But you will never be so productive in the face of changing requirements.