3 ms·

I find the phrase 'Technical Debt' to be unhelpful. If I am in financial debt I will definitely need to pay it off unless I go through bankruptcy. Technical 'De

I find the phrase 'Technical Debt' to be unhelpful. If I am in financial debt I will definitely need to pay it off unless I go through bankruptcy. Technical 'Debt' seems to operate by bad analogy: I may opt to completely wipe out the subsystem that has accrued the debt and replace it with something else, or it could turn out that the subsystem solves some problem that wasn't business-critical anyhow. I've had to restrain developers from "turd polishing" systems that were poorly thought out to begin with. Code gardening in a subsystem that was simply the algorithmically wrong way of doing it (that we might have had to have shipped quickly in order to stay afloat) isn't a first class activity. The problem is with the metaphor of technical 'debt' is that implies a balance sheet, but many (most?) of these bills will never come due.

Forge36 7y ago
That's the difficult part of being new on a project. If you aren't building the replacement is progress being made to fix the issue. With regards to gardening: if you're spending all your time weeding but you haven't planted any seeds what are you growing?
- glangdale 7y ago
  Hopefully the manager has enough sense to help a new person see the priorities. As a manager I've definitely 'called time' on weeding. Good analogy.
wccrawford 7y ago
Technical debt really applies when time-saving decisions in the past cost more time in the future. As such, you can't always be 100% sure whether you're incurring it at the time or not. You can only be sure later, once you have to pay it. But there are definitely times that you feel certain it's going to end up being technical debt. When you implement a system that doesn't scale, but you know it has to eventually scale massively, that's going to be technical debt. You could write it right now to handle that load, but it'd take a lot of time and money. Or you could write it the quick and dirty way, and get money coming in immediately and put off the scaling until it's actually necessary. You know it's coming. But you decided to incur that debt in order to make money sooner. IME, technical debt is usually about time or money, and getting something done cheaply now and worrying about the full cost later when it's more applicable. It's a tool, not a problem, so long as you're managing it and not just blindly choosing to do things the quick and dirty way all the time.

Forge36 7y ago

That's the difficult part of being new on a project. If you aren't building the replacement is progress being made to fix the issue. With regards to gardening: if you're spending all your time weeding but you haven't planted any seeds what are you growing?

glangdale 7y ago
Hopefully the manager has enough sense to help a new person see the priorities. As a manager I've definitely 'called time' on weeding. Good analogy.

wccrawford 7y ago

Technical debt really applies when time-saving decisions in the past cost more time in the future. As such, you can't always be 100% sure whether you're incurring it at the time or not. You can only be sure later, once you have to pay it. But there are definitely times that you feel certain it's going to end up being technical debt. When you implement a system that doesn't scale, but you know it has to eventually scale massively, that's going to be technical debt. You could write it right now to handle that load, but it'd take a lot of time and money. Or you could write it the quick and dirty way, and get money coming in immediately and put off the scaling until it's actually necessary. You know it's coming. But you decided to incur that debt in order to make money sooner. IME, technical debt is usually about time or money, and getting something done cheaply now and worrying about the full cost later when it's more applicable. It's a tool, not a problem, so long as you're managing it and not just blindly choosing to do things the quick and dirty way all the time.