4 ms·
Can we stop using the term Technical Debt? First objection: Managers and Business persons understand Debt, like it and use it. I use credit cards and have a ca
by lowbloodsugar 6y ago
Can we stop using the term Technical Debt?
First objection: Managers and Business persons understand Debt, like it and use it. I use credit cards and have a car loan. If we, as engineers, present the problem as "You can have what you want now, but you will incur Technical Debt" then any sane person will say "Sure! Good deal!" Ask yourself, how many times a manager or business owner has asked "What is the interest rate?" Zero times.
Second Objection: It's not debt.
Debt would be if someone said "I need to build a bridge across here that can handle an Army, and I've got $1m", we engineers reply "It will take $2m", and they respond "Ok, I will borrow $1m so you can build the bridge I need".
Instead what happens is they say "Well, build what you can for $1m", and you say "Ok, we can make 'a bridge' for that", and then either (a) your infantry can cross, but the tanks have to get diverted 20 miles out of the way, or (b) the tanks end up in the river along with the bridge. Since (b) is bad, you then have to spend a lot of time planning the routes for the tanks, and making sure the tanks have the right air cover, etc etc, i.e. doing more work.
It's not debt. It's just (at best) an incomplete solution or (at worst) a bad solution that fails at the worst possible moment - e.g. database collapses during registration for the largest event of the year.
Ah, but surely, if you build the lightweight solution for $1m, and acknowledge the increased costs of managing the problems that it doesn't solve, then thats fine? Sure, but that's not technical debt either! That is scoping: we (engineers + business) identify a workable solution that provides some business value. And then we do that well.
- dredmorbius 6y agoCunningham makes a convincing case for the teerm: https://youtube.com/watch?v=pqeJFYwnkjE https://youtube.com/watch?v=pqeJFYwnkjE (4m44s)
- lowbloodsugar 6y agoHe made a convincing case for why its like "debt", but he fails to make a convincing case for its use, or any case at all that using the term has a positive impact on a team's success. He even calls out that some teams think they don't have to pay back the debt. I think that is the norm, and that's the problem of debt. When financial people use debt, that debt comes with structure and consequence: it might be monthly payments or it might be due sometime in the future. Offer such people a "debt" that has nobody enforcing it, nobody quantifying it and of course it wont be paid back. Agile engineers making scary "booga booga" noises about "we need to refactor" just don't carry the same weight as not being able to make payroll because your note is due. And yet that seems surprising to engineers.
- dredmorbius 6y agohe fails to make a convincing case for its use Incorrect. He notes that debt (finanial or technical) is useful in getting things done more quickly, but must be repaid. Technical debt enables getting a minimal product or prototype out to gain experience and further refine design. It is specifically contrasted with bad software. Deficiencies are to be addressed later. And yes you're correct in that this last step is often omitted.
- lowbloodsugar 6y agoMy point is that the "debt" metaphor is what doesn't work, not the strategy of doing less work upfront. Specifically, having a scoping conversation, or a YAGNI conversation, or a "debt" conversation results in less work being done upfront. However, if the conversation is one of "debt", then, in my experience, the necessary work is not done later, because there is no organization demanding repayment.
- razius 6y agoI keep thinking the same, did you find a good solution for it? My thinking is to argue to the business to schedule some dedicated time for "investments" to make the iterations faster.
- lowbloodsugar 6y agoI'm sorry to tell you that the only solution that has ever worked for me is to leave and join a company where engineers make those decisions.