Hacker News Reader

Comment by pif | Hacker News Reader

> 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.

View on HN

> 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.

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).

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.

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.

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

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.

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.

Quick and dirty is always dirty, but not necessarily quick.

Reply on news.ycombinator.com