Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Great article, loved how the examples were presented.

In my time as an engineer, I've found that thinking of tech debt as financial debt also helps. There is the initial convenience (borrowed money) of using the debt-ed approach. Then there is fix cost as Bill Clark name it, i.e. how much to pay back the debt if it were money. The impact is akin to the amortization schedule, i.e. what is the cost every time. For normal money, amortization schedule is over time, but for tech debt it is over usage. The amortization schedule of tech debt is discounted over time, as with money, _now_ is more important that _later_.

Contagion is a great concept, and I think it is a better name than interest rate, as the debt will spread through the system, and not just linearly with time.

Tech debt is also multi-dimensional and not fungible like money, which makes it a harder thing to reason about.

But the good news is, in my opinion, that sometimes it is perfectly fine to default on some tech debt, and never pay it back, delete the code. Then taking that tech debt was a win, if the convenience was more than the amortized payments.



I think the main difference is that technical debt is not fungible, i.e. you can’t necessarily easily choose to pay off the highest-interest technical debts first like you would for your personal financial debt.


put another way: you can have one item that is 5 days of work but really critical and another that’s 2 days of work but way less critical. If you have 2 days to work on tech debt, you basically are forced to do the 2 day one. especially since you are evaluated on what you finish, not how much you worked towards some long goal.


As financial analogy, I've seen a piece (linked on HN a few years ago) comparing technical debt to unhedged options, meaning you can get a benefit and you might or might not get bitten by it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: