6 ms·

I like the framing of tech debt as value-neutral; whether it's good or bad depends on how you use it (just like financial debt). Of course, all else being equal

I like the framing of tech debt as value-neutral; whether it's good or bad depends on how you use it (just like financial debt). Of course, all else being equal, you'd rather have zero debt. One higher level consideration that's particularly relevant for early-stage startups, is that you often simply don't have time to build the ideal "tech-debt free" solution. Focusing on 80/20 solutions almost necessarily involves adding tech debt. However, if you're mindful about where you take on tech debt, and commit to tapering and then paying it down as your resources grow, then you're more likely to avoid the debt spiral where your development grinds to a halt, due to everything breaking all the time. One other point I'd make is that a common form of "tech debt" for early-stage startups is simply doing things that don't scale; it's often beneficial to make your domain models flexible so that you can support one-off manual interactions, for example if a new customer appears that requires it. Then automate that thing and constrain the domain actions once you have collected enough use-cases to know what makes sense to forbid.

WorldMaker 7y ago
I like to point out as well that it isn't tech "debt" if there's no "IOU". For instance, in the hard-coding example, it's conventional wisdom to avoid hard-coded magic constants for a few reasons including it sometimes is hard to figure out later why a magic constant was used, and in an if/else branch situation like that maybe tough to figure out when you can cleanly refactor those branches. If the case is well documented (it's the date of a given feature release) and the code reasonably factored already (the "off" branch isn't a ticking time bomb bug that needs to be removed after the date in question), then it may be a code smell, but it isn't necessarily an IOU to a future developer (such as yourself), so it isn't necessarily "tech debt", it was just a trade off made at the time. Of course, if a future developer adopts a hard linter rule against that sort of code smell, they may come to see it is tech debt retrospectively, but that's also where the analogy starts to get fuzzy. (Pushing the analogy to a breaking point: Is adding a linter then, doing an audit and depreciating assets for "tech taxes"? Come to think of it "tech taxes" would be a fun alternative term to add to the "tech debt" family. "Hold on, just paying my tech taxes; npm install, npm audit, and npm run lint.")
- Gibbon1 7y ago
  I have a good example of no IOU. Friend 20 years ago worked on a content streaming platform. They needed a dispatcher and someone wrote one in TCL in a week. Just to get something working. And they never got around to replacing it because it worked 'fine'. Turned out while everything else needed to be hyper efficient and scale the dispatcher not really.
  - aeorgnoieang 7y ago
    An unexpected tech debt jubilee!
- LargeWu 7y ago
  A good talk about the "technical debt" metaphor. https://www.youtube.com/watch?v=XakfJ2spb3w https://www.youtube.com/watch?v=XakfJ2spb3w tl;dr: Technical debt can be categorized on 2 axes: Planned vs unplanned, and high interest vs. low interest. Interest is paid down in pain. If you are not experiencing any pain, it's not actually tech debt. Low interest, planned tech debt (akin to a mortgage) is ok because presumably the cost of the interest is lower than the returns. High interest, unplanned tech debt (akin to a loan shark, or pawn shop) is best to be avoided, because you're experiencing a lot of pain probably without a clear vision for paying it off. You're just continually paying the interest/experiencing pain.
spc476 7y ago
I don't like the metaphor. With financial debt, you get $X up front for $Y (where Y >= X) and pay $Y amount over N months. It's known up front what it's costing you (Y - X) over what time span (N). If the difference between Y-X is low, congrats! You got a great interest rate. If it's large, well, good luck! But in both those cases, the pain is known up front. The discussion here seems to be no one knows what X is, nor Y, but it's expected that Y > X by some large amount that you may or may not have to pay off. Crazy!
- munk-a 7y ago
  I disagree about the pain being known up front - you are aware of an obligation and that obligations units in dollars, but how those dollars translate into future missed opportunities is unknown... additionally you always have some risk due to currency fluctuations if you're operating an international business, if you're primarily operating in AUD and payroll is in AUD but the loan repayment is in USD then a profitable quarter may end up being much less able to pay down your debt. I agree that money is much more comprehensible, but there isn't so as stark a difference in knownability as it might initially appear.
- theptip 7y ago
  The aspects of debt that you're focusing on aren't really relevant to how I use this metaphor. Rather than trying to use the tech debt metaphor to actually calculate the interest rate, I think it's more useful at a higher level of abstraction. When faced with the product decision to do more work now and build something better, or less work now and cut corners, what are the consequences of doing less? Without some way of conveying the long-term costs, your stakeholders will always push you to do the least work possible to tick the box. The debt analogy is a universally-understood way of conveying the fact that if you cut corners, you'll likely pay interest later in the form of slower development speed. And if you take on too much debt, then all your spend will be going to paying off your interest, and your progress will stall. Non-technical people understand this analogy, and so it's a useful way of conveying the shape of the problem without having to start from first-principles.

WorldMaker 7y ago

I like to point out as well that it isn't tech "debt" if there's no "IOU". For instance, in the hard-coding example, it's conventional wisdom to avoid hard-coded magic constants for a few reasons including it sometimes is hard to figure out later why a magic constant was used, and in an if/else branch situation like that maybe tough to figure out when you can cleanly refactor those branches. If the case is well documented (it's the date of a given feature release) and the code reasonably factored already (the "off" branch isn't a ticking time bomb bug that needs to be removed after the date in question), then it may be a code smell, but it isn't necessarily an IOU to a future developer (such as yourself), so it isn't necessarily "tech debt", it was just a trade off made at the time. Of course, if a future developer adopts a hard linter rule against that sort of code smell, they may come to see it is tech debt retrospectively, but that's also where the analogy starts to get fuzzy. (Pushing the analogy to a breaking point: Is adding a linter then, doing an audit and depreciating assets for "tech taxes"? Come to think of it "tech taxes" would be a fun alternative term to add to the "tech debt" family. "Hold on, just paying my tech taxes; npm install, npm audit, and npm run lint.")

Gibbon1 7y ago
I have a good example of no IOU. Friend 20 years ago worked on a content streaming platform. They needed a dispatcher and someone wrote one in TCL in a week. Just to get something working. And they never got around to replacing it because it worked 'fine'. Turned out while everything else needed to be hyper efficient and scale the dispatcher not really.
- aeorgnoieang 7y ago
  An unexpected tech debt jubilee!
LargeWu 7y ago
A good talk about the "technical debt" metaphor. https://www.youtube.com/watch?v=XakfJ2spb3w https://www.youtube.com/watch?v=XakfJ2spb3w tl;dr: Technical debt can be categorized on 2 axes: Planned vs unplanned, and high interest vs. low interest. Interest is paid down in pain. If you are not experiencing any pain, it's not actually tech debt. Low interest, planned tech debt (akin to a mortgage) is ok because presumably the cost of the interest is lower than the returns. High interest, unplanned tech debt (akin to a loan shark, or pawn shop) is best to be avoided, because you're experiencing a lot of pain probably without a clear vision for paying it off. You're just continually paying the interest/experiencing pain.

spc476 7y ago

I don't like the metaphor. With financial debt, you get $X up front for $Y (where Y >= X) and pay $Y amount over N months. It's known up front what it's costing you (Y - X) over what time span (N). If the difference between Y-X is low, congrats! You got a great interest rate. If it's large, well, good luck! But in both those cases, the pain is known up front. The discussion here seems to be no one knows what X is, nor Y, but it's expected that Y > X by some large amount that you may or may not have to pay off. Crazy!

munk-a 7y ago
I disagree about the pain being known up front - you are aware of an obligation and that obligations units in dollars, but how those dollars translate into future missed opportunities is unknown... additionally you always have some risk due to currency fluctuations if you're operating an international business, if you're primarily operating in AUD and payroll is in AUD but the loan repayment is in USD then a profitable quarter may end up being much less able to pay down your debt. I agree that money is much more comprehensible, but there isn't so as stark a difference in knownability as it might initially appear.
theptip 7y ago
The aspects of debt that you're focusing on aren't really relevant to how I use this metaphor. Rather than trying to use the tech debt metaphor to actually calculate the interest rate, I think it's more useful at a higher level of abstraction. When faced with the product decision to do more work now and build something better, or less work now and cut corners, what are the consequences of doing less? Without some way of conveying the long-term costs, your stakeholders will always push you to do the least work possible to tick the box. The debt analogy is a universally-understood way of conveying the fact that if you cut corners, you'll likely pay interest later in the form of slower development speed. And if you take on too much debt, then all your spend will be going to paying off your interest, and your progress will stall. Non-technical people understand this analogy, and so it's a useful way of conveying the shape of the problem without having to start from first-principles.