5 ms·

> If you’re building a new feature, there’s often a choice between doing it “right” and doing it “quick”. It's really surprising how often the “quick” approach

> If you’re building a new feature, there’s often a choice between doing it “right” and doing it “quick”. It's really surprising how often the “quick” approach turns out to be slower than the “right” approach. Now sure, there's such a thing as focusing too much on non-market relevant aspects of a project, or going down rabbit holes, or designing and coding for a future that will almost certainly never come, but it still continues to surprise me how often when the choice is between "quick" or "right", that "quick" actually turns surprisingly soon into slow. There's a saying apparently in use in the military "slow is smooth, smooth is fast". That's the kind of wisdom we need to aim for in software engineering. "More haste, less speed". Oh yeah, the other difference is that there's no external force that will take you to court if you don't pay down technical debt, so in fact most organisations are terrible at paying it down. If you don't literally have a plan on the calendar with names and dates committed to improve the code, you're most likely fooling yourself by calling it technical debt. The true metaphor is much closer to 'Superfund site'.

resters 4y ago
> It's really surprising how often the “quick” approach turns out to be slower than the “right” approach. It depends on what is done fast and what is done more thoughtfully. For example, if the general architecture is thought through carefully, individual modules can be built more hastily and later rewritten. On the other hand if the architecture is unsuitable for the problem, then it matters little how well tested or high quality any of the code is, and overdoing code quality will be a waste of time. It comes down to judgment and tradeoffs (like everything in engineering). I like the concept of tech debt because it is a way of describing a class of tradeoffs.
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?
cptskippy 4y ago
In my experience, tech debt can surface at many levels and isn't always because someone took the wrong or quick approach. Sometimes it's the best option you have at the time. This happens a lot when you have small teams working on many projects for different business units that have strict time constraints. For example our call center needed staff availability surfaced in the CRM for routing calls. This required data from the HRMS and the individual's work calendar. We knew the HRMS system was being replaced in Q4 of this year, but the project timeline dictated this feature would release in Q2. Thus we have a tech debt item added to the backlog to refactor this integration when the new HRMS system is launched. Another example that comes to mind happened a few years back. We had a product using a framework that was falling out of support. That itself was naturally emergent tech debt. When the tech debt item was finally added to a sprint, the upgrade options were to a LTS version or an STS version after that. The feature that had delayed the tech debt for so long had been refactored again for the STS. The decision was made to skip the LTS version in favor of the STS version because it would save a huge refactor in the future. However being an STS version, it necessitated another tech debt item to upgrade to an LTS version in a year.
- kybernetikos 4y ago
  I suppose this shows the flexibility of the term, because none of these sound like tech debt to me. Your first one is just a new requirement (to integrate with a new system) that you can see coming down the road. You didn't make a decision that took on any 'technical debt' there. Your second one is that the framework you were using fell out of support. Unless you had previously decided to use an old version because it would allow you to release earlier, you didn't take on tech debt here, you just needed to do some work to stay on a supported version of the framework. Your last example where you chose to go to an STS version instead of an LTS version might be a good example, since you made a decision that forced you to do some upgrade work in the future sooner than you would otherwise have had to. On the other hand, it doesn't seem that you took on technical debt in making that decision, if anything, your tech is probably better and less indebted than if you hadn't. Perhaps I'd say you took on schedule debt or something else there. I suspect that you work for an organisation where anything that isn't a customer requested feature is considered 'tech debt', but I think that's a too wide use of the term.

resters 4y ago

> It's really surprising how often the “quick” approach turns out to be slower than the “right” approach. It depends on what is done fast and what is done more thoughtfully. For example, if the general architecture is thought through carefully, individual modules can be built more hastily and later rewritten. On the other hand if the architecture is unsuitable for the problem, then it matters little how well tested or high quality any of the code is, and overdoing code quality will be a waste of time. It comes down to judgment and tradeoffs (like everything in engineering). I like the concept of tech debt because it is a way of describing a class of tradeoffs.

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?

cptskippy 4y ago

In my experience, tech debt can surface at many levels and isn't always because someone took the wrong or quick approach. Sometimes it's the best option you have at the time. This happens a lot when you have small teams working on many projects for different business units that have strict time constraints. For example our call center needed staff availability surfaced in the CRM for routing calls. This required data from the HRMS and the individual's work calendar. We knew the HRMS system was being replaced in Q4 of this year, but the project timeline dictated this feature would release in Q2. Thus we have a tech debt item added to the backlog to refactor this integration when the new HRMS system is launched. Another example that comes to mind happened a few years back. We had a product using a framework that was falling out of support. That itself was naturally emergent tech debt. When the tech debt item was finally added to a sprint, the upgrade options were to a LTS version or an STS version after that. The feature that had delayed the tech debt for so long had been refactored again for the STS. The decision was made to skip the LTS version in favor of the STS version because it would save a huge refactor in the future. However being an STS version, it necessitated another tech debt item to upgrade to an LTS version in a year.

kybernetikos 4y ago
I suppose this shows the flexibility of the term, because none of these sound like tech debt to me. Your first one is just a new requirement (to integrate with a new system) that you can see coming down the road. You didn't make a decision that took on any 'technical debt' there. Your second one is that the framework you were using fell out of support. Unless you had previously decided to use an old version because it would allow you to release earlier, you didn't take on tech debt here, you just needed to do some work to stay on a supported version of the framework. Your last example where you chose to go to an STS version instead of an LTS version might be a good example, since you made a decision that forced you to do some upgrade work in the future sooner than you would otherwise have had to. On the other hand, it doesn't seem that you took on technical debt in making that decision, if anything, your tech is probably better and less indebted than if you hadn't. Perhaps I'd say you took on schedule debt or something else there. I suspect that you work for an organisation where anything that isn't a customer requested feature is considered 'tech debt', but I think that's a too wide use of the term.