3 ms·

> It's really surprising how often the “quick” approach turns out to be slower than the “right” approach. And it's really surprising how few people realise tha

by pif 4y ago

> It's really surprising how often the “quick” approach turns out to be slower than the “right” approach. And it's really surprising how few people realise that, even if the "quick" approach is slower in the long term, time is not always worth the same! Time just before release is precious. Just after release, instead, you are both tired anyway and still have your code in your head, so that is the right time to refactor. In the end, technical debt, code quality, and whatever code metric... they only make sense for code that has been shipped. The code you are refining is worth nothing if users are not already using it.

nicoburns 4y ago
I think the point is that often the "quick" approach is slower even in the short term. Meaning you end with hacky, poor quality code for no benefit. It isn't always the case, but it often is.
- HelloNurse 4y ago
  Quick and dirty is always dirty, but not necessarily quick.
kybernetikos 4y ago
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.
ilyt 4y ago
> And it's really surprising how few people realise that, even if the "quick" approach is slower in the long term, time is not always worth the same! That really only applies to "we have to launch it next week". In vast majority of projects longer than a hackathon doing even slightly better (let's say extra 20%) pays off very quickly. Because there is plenty more shades between "let's do that in immediately simplest way with zero thinking" vs "let's build our own DB engine to handle the problem". With exception being maybe "we're just prototyping few approaches to the problem" The "but we need to be agile and launch fast" is more often excuse than legitimate reason.
- tsgagnon 4y ago
  That really only applies to "we have to launch it next week". It can potentially apply to any project with a fixed budget, whether that's internal or external. And time is money, sometimes quite literally if you are working in the agency world. Customers will choose a project with a $50k budget versus a $80k budget even if smaller budget will be significantly worse, as long as it meets one of their basic needs (or even if it doesn't, if that's all the budget they have to work with).

by pif 4y ago

nicoburns 4y ago

I think the point is that often the "quick" approach is slower even in the short term. Meaning you end with hacky, poor quality code for no benefit. It isn't always the case, but it often is.

HelloNurse 4y ago
Quick and dirty is always dirty, but not necessarily quick.

kybernetikos 4y ago

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.

ilyt 4y ago

> And it's really surprising how few people realise that, even if the "quick" approach is slower in the long term, time is not always worth the same! That really only applies to "we have to launch it next week". In vast majority of projects longer than a hackathon doing even slightly better (let's say extra 20%) pays off very quickly. Because there is plenty more shades between "let's do that in immediately simplest way with zero thinking" vs "let's build our own DB engine to handle the problem". With exception being maybe "we're just prototyping few approaches to the problem" The "but we need to be agile and launch fast" is more often excuse than legitimate reason.

tsgagnon 4y ago
That really only applies to "we have to launch it next week". It can potentially apply to any project with a fixed budget, whether that's internal or external. And time is money, sometimes quite literally if you are working in the agency world. Customers will choose a project with a $50k budget versus a $80k budget even if smaller budget will be significantly worse, as long as it meets one of their basic needs (or even if it doesn't, if that's all the budget they have to work with).