3 ms·

I'm not even talking about 'in the long term'. I have often seen developers weigh up doing it 'right' or doing it 'quick', and the 'quick' solution turns out t

I'm not even talking about 'in the long term'. I have often seen developers weigh up doing it 'right' or doing it 'quick', and the 'quick' solution turns out to have more complexity than originally anticipated, and take a lot longer than expected. Sometimes the reason the 'quick' way seemed quick was just because the problems with it were less understood. The 'right' solution generally is harder, but the 'right' solution is better understood, and people can be surprisingly productive on things they understand and believe in when they knuckle down and get to it.

jakelazaroff 4y ago
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.
xboxnolifes 4y ago
Sounds like it wasn't actually the quick solution then?
- kybernetikos 4y ago
  Indeed, that's the point I'm making. Very often (not always, but much more than most people would think) the 'quick' solution that people are suggesting will not actually be any quicker to implement than the 'right' solution, and if you chased an illusory short cut, you end up with a timeline that is no better and an architecture that is worse and either forces future work onto you or slows down your future work or saddles you with a bunch of unnecessary maintenance.

jakelazaroff 4y ago

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.

xboxnolifes 4y ago

Sounds like it wasn't actually the quick solution then?

kybernetikos 4y ago
Indeed, that's the point I'm making. Very often (not always, but much more than most people would think) the 'quick' solution that people are suggesting will not actually be any quicker to implement than the 'right' solution, and if you chased an illusory short cut, you end up with a timeline that is no better and an architecture that is worse and either forces future work onto you or slows down your future work or saddles you with a bunch of unnecessary maintenance.