> But more importantly, it locks in an experience before you’re sure it’s right.
This single sentence communicates more than the author intended. I see the phenomena all the time: poorly architected systems that are brittle in face of user requirement changes. In the extreme case, a new widget or input on the UI echoes all the way to the database, touching and mutating every layer in between.
So, it is a perfectly valid matter to weigh the benefits of optimistic and forward looking engineering vs gaining deeper understanding of a market faster. This is a valid consideration. But if anyone tells you that going down any other path other than tacking on bits and pieces on the way "as we learn" is an error because of "user experience" (other than, ahem, performance) then be certain, certain, that the speaker lacks the necessary technical understanding to be offering strategic technical advice.
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.”
This single sentence communicates more than the author intended. I see the phenomena all the time: poorly architected systems that are brittle in face of user requirement changes. In the extreme case, a new widget or input on the UI echoes all the way to the database, touching and mutating every layer in between.
So, it is a perfectly valid matter to weigh the benefits of optimistic and forward looking engineering vs gaining deeper understanding of a market faster. This is a valid consideration. But if anyone tells you that going down any other path other than tacking on bits and pieces on the way "as we learn" is an error because of "user experience" (other than, ahem, performance) then be certain, certain, that the speaker lacks the necessary technical understanding to be offering strategic technical advice.