5 ms·

> Payments couldn’t be processed in different currencies > If the delivery system is offline, the code wouldn’t work > Users with deactivated accounts could sti

> Payments couldn’t be processed in different currencies > If the delivery system is offline, the code wouldn’t work > Users with deactivated accounts could still access the system > No automated testing > And this, my friends, is what we know as Technical Debt. I do not describe that as technical debt. That are mostly lack of features. The code could be fantastic and it is just that to support different currencies, disable accounts or similar things new code is needed. The lack of automated testing is more in line on what I think that it is technical debt. Details aside it is an interesting read.

bananaface 6y ago
I wouldn't even say lack of testing is technical debt - it's just another feature that isn't implemented. Once you implement it, problem's solved. It doesn't make the system worse/more expensive as it grows, and it doesn't become more costly to "fix" the bigger the system gets. IMO those are the operative features of tech debt.
- yoz-y 6y ago
  If you always have a perfect vision of your software and the team is very small then I would agree. (I.e.: I don’t write tests for my hobby projects) But testing is mainly important so a developer not familiar with the program will not break it by modifying something seemingly unrelated. Lack of tests will absolutely bite you.
  - bananaface 6y ago
    I agree, I just wouldn't call it tech debt. It doesn't become more expensive to fix over time, except for the bump when you forget how the original code works. There's no metaphorical "interest" that you draw down on.
- Hokusai 6y ago
  > I wouldn't even say lack of testing is technical deb You are right, it depends on the kind of application and circumstances testing can be done in different ways. There is occasions were instead of automated testing there are other ways of working with quality. But, in this case automated testing is in the list of things that needs to be done. So, I think that to want automated testing and not have them is technical debt.
  - bananaface 6y ago
    I said this below but I like to distinguish technical debt as having metaphorical "interest" - specifically, it becomes more expensive to pay back the longer you leave it, the ball of debt grows over time. It's stuff that gets baked into a product, and then is difficult (or impossible) to un-bake, and gets more difficult the more the product grows around it. Aside from the initial increase in cost when you forget how the original code worked, tests are no more expensive to write in a year as they are today. Not significantly, at least. So I'd just class them as incomplete product - the effects are negative and can be expensive, but it doesn't dig you into a hole.
LASR 6y ago
Yeah this is not technical debt at all. These are examples of launch-aborting bad bugs. If we try to characterize the "perfect" example of technical debt: - There is a spec, say: v1, of how the product must behave to the user. - The product behaves exactly as defined in v1. I.e.: There are zero bugs. - The very next iteration (v2) of this product has some cost to achieve. - There is a counterfactual set of decisions that could have been made, which would make achieving v2 have the minimal possible cost. Debt is the delta between the set of decisions made in implementing v1 vs the counterfactual set of decisions not made in implementing v1 that would have made the cost of implementing v2 minimal. This definition has all the familiar mechanics of technical debt. - You don't need to pay the debt to achieve v2 perfectly - it would just be more expensive. - If all you ever want to do is v1, ie: there is no v2, then there is no technical debt, no matter how ugly the code is for v1. - You can choose to reallocate costs between v1 and v2 freely. The distribution of costs will affect launch timelines, but will have no effect on the user-visible quality of either version. It's dangerous not to understand the difference between bugs and technical debt. I lost interest in reading this article after it seemed like the author did not understand this basic difference.

bananaface 6y ago

I wouldn't even say lack of testing is technical debt - it's just another feature that isn't implemented. Once you implement it, problem's solved. It doesn't make the system worse/more expensive as it grows, and it doesn't become more costly to "fix" the bigger the system gets. IMO those are the operative features of tech debt.

yoz-y 6y ago
If you always have a perfect vision of your software and the team is very small then I would agree. (I.e.: I don’t write tests for my hobby projects) But testing is mainly important so a developer not familiar with the program will not break it by modifying something seemingly unrelated. Lack of tests will absolutely bite you.
- bananaface 6y ago
  I agree, I just wouldn't call it tech debt. It doesn't become more expensive to fix over time, except for the bump when you forget how the original code works. There's no metaphorical "interest" that you draw down on.
Hokusai 6y ago
> I wouldn't even say lack of testing is technical deb You are right, it depends on the kind of application and circumstances testing can be done in different ways. There is occasions were instead of automated testing there are other ways of working with quality. But, in this case automated testing is in the list of things that needs to be done. So, I think that to want automated testing and not have them is technical debt.
- bananaface 6y ago
  I said this below but I like to distinguish technical debt as having metaphorical "interest" - specifically, it becomes more expensive to pay back the longer you leave it, the ball of debt grows over time. It's stuff that gets baked into a product, and then is difficult (or impossible) to un-bake, and gets more difficult the more the product grows around it. Aside from the initial increase in cost when you forget how the original code worked, tests are no more expensive to write in a year as they are today. Not significantly, at least. So I'd just class them as incomplete product - the effects are negative and can be expensive, but it doesn't dig you into a hole.

LASR 6y ago

Yeah this is not technical debt at all. These are examples of launch-aborting bad bugs. If we try to characterize the "perfect" example of technical debt: - There is a spec, say: v1, of how the product must behave to the user. - The product behaves exactly as defined in v1. I.e.: There are zero bugs. - The very next iteration (v2) of this product has some cost to achieve. - There is a counterfactual set of decisions that could have been made, which would make achieving v2 have the minimal possible cost. Debt is the delta between the set of decisions made in implementing v1 vs the counterfactual set of decisions not made in implementing v1 that would have made the cost of implementing v2 minimal. This definition has all the familiar mechanics of technical debt. - You don't need to pay the debt to achieve v2 perfectly - it would just be more expensive. - If all you ever want to do is v1, ie: there is no v2, then there is no technical debt, no matter how ugly the code is for v1. - You can choose to reallocate costs between v1 and v2 freely. The distribution of costs will affect launch timelines, but will have no effect on the user-visible quality of either version. It's dangerous not to understand the difference between bugs and technical debt. I lost interest in reading this article after it seemed like the author did not understand this basic difference.