IMO this is a different problem. If you’re building something without fully understanding it, you’re not really making a choice about the tradeoffs. And this ca

IMO this is a different problem. If you’re building something without fully understanding it, you’re not really making a choice about the tradeoffs. And this can happen no matter how “right” you try to build it. I’ve seen plenty of projects go off the rails because the team tried to encapsulate everything perfectly and ended up with bad abstractions that made future development a chore. The best “quick” vs. “right” decisions I’ve made (and this is not a binary) have involved 1) complete plans for both implementations, 2) a plan to migrate from “quick” to “right” and sometimes 3) a plan to remove the “quick” implementation if the feature turns out to be unneeded. It involves more upfront planning work, not less. 3 is particularly useful because it forces you to come up with the loosest possible coupling between the new feature and the existing system.