Hacker News Reader

Comment by LargeWu | Hacker News Reader

This is my favorite explanation of technical debt, framed as actual debt instruments. Mortgages, credit cards, etc.

https://www.youtube.com/watch?v=XakfJ2spb3w

tl;dw: Technical debt is equivalent to the interest you are paying on it, where interest == pain. Some debt is planned and low interest, like a mortgage. Other debt is unplanned and high interest, like a credit card or payday loan. Sometimes that interest allows you to get larger returns. For example, if you could take out a loan at 3% in order to invest at 8% over the life of the loan, that's a pretty good deal, as long as you can pay it down. but, if you let that interest get out of control, if you don't pay down the principal, then it becomes more painful.

View on HN

I really like a post I saw awhile back that refines the idea of technical debt as an unhedged call option. (Original link is dead, so here's the wayback machine link and the HN thread.)

https://web.archive.org/web/20161223143702/http://higherorde... https://news.ycombinator.com/item?id=8777237

From the post:

> Call options are a better model than debt for cruddy code (without tests) because they capture the unpredictability of what we do. If I slap in an a feature without cleaning up then I get the benefit immediately, I collect the premium. If I never see that code again, then I’m ahead and, in retrospect, it would have been foolish to have spent time cleaning it up.

> On the other hand, if a radical new feature comes in that I have to do, all those quick fixes suddenly become very expensive to work with. Examples I’ve seen are a big new client that requires a port to a different platform, or a new regulatory requirement that needs a new report. I get equivalent problems if there’s a failure I have to interpret and fix just before a deadline, or the team members turn over completely and no-one remembers the tacit knowledge that helps the code make sense. The market has moved away from where I thought it was going to be and my option has been called.

interesting fact is that selling options is strategy called Selling Volatility, meaning you bet that things will slow down and normalize.

When applied to tech debt, it can be thought of as betting that product velocity will slow down, and you will have time to refactor/reliminate tech debt sometime later.

Of course when developing new product/startup product velocity only increases over time. And if you did accumulate tech debt - there will be some time when you will have to rewrite stuff from scratch, because refactoring and/or maintaining codebase will become unfeasible.

and it leads to conclusion that the best time to take on technical debt - is maintaining stable product, when product velocity is slow. you implement change quickly, then over time you refactor it. Which actually perfectly aligns with some agile methodologies (XP).

Yes, this is much better framing.

Originally I wanted to write that there are two different things that get called "technical debt". In one case, the choice is between "clean code now" and "quick and dirty code now, sell version 1.0 to pay the bills, refactor the code, publish version 1.1". In the other case, the choice is between "clean code for more money" and "quick and dirty code for less money" with no itention to fix it later.

Technically, only the first case should be called "debt". But sometimes managers pretend it's the first case, when actually it is the second case, to help developers save some face. So the developers keep adding "refactor XY, priority: low" to the backlog, and then at some moment the developers are moved to a new project, and the backlog gets silently deleted.

Then again, sometimes a big change is needed unexpectedly, and all those issues that were originally planned to silently die in the backlog suddenly need to be addressed. So, in this case, the "technical debt" was actually a bet that this situation is unlikely to happen. (Or maybe that it will happen in a sufficiently far future so that it will be another manager's problem.)

I’ve had some success with non technical people and a warehouse metaphor.

Can you keep shipping products if you never tidy up? Yes it’s possible but eventually it catches up to you.

There’s no specific point in time at which tidying up a warehouse is going to make or break a business but the untidy ones are more likely to be hard to hire for and more likely to catch fire.

And they’ll definitely slow down ability to ship products.

Warehouses that stay tidy have a predictable rate of shipping and reduced risks of accidents and fires.

Do you need to put that one single item in the right place every time to continue to ship anything? Well the answer is always no, but permanent short term thinking like that without ever tidying will always eventually cost you in the end.

Much easier to keep on top of it. Workers and new hires are also more effective.

I find that this metaphor doesn’t feel forced or stretched and it’s pretty intuitive and nicely harmonises with products and shipping terms that people use for software anyway.

Makes sense. I can imagine it working on non-tech people more easily. It sounds similar to an explanation of why people should keep their house tidy then.

Yeah but the big difference with technical debt and fiscal debt is that with technical debt you can remove debt by changing requirements.

Like a kind of inflation that devalues both code written and associated technical debt.

changing requirement is just semantic/language trick. the reality (market forces) will eventually catch up in form of angry customer/regulator demanding the asked feature asap, or frustrated clients leaving for competition, etc

I also like the term - "Software Decay" - if not nurtured well.

Reply on news.ycombinator.com