I worked with Ward Cunningham for about a year, and he said once that he regretted coining the phrase “technical debt.” He said it allowed people to think of the debt in a bottomless way: once you’ve accumulated some, why not a little more? After all, the first little bit didn’t hurt us, did it?
The end result of this thinking is the feature factory, where a company only ever builds new features, usually to attract new customers. Necessary refactors are called “tech debt” and left to pile up. Yes, this is just another view of bad management, but still, Ward thought that the metaphor afforded it too easily.
He said he wished instead that he’d coined “opportunity,” as in, producing or consuming it. Good practices produce opportunity. Opportunity can then be consumed in order to meet certain short-term goals.
So it flips the baseline. Rather than having a baseline of quality then dipping below it into tech debt, you’d produce opportunity to put you above the baseline. Once you have this opportunity, you consume it to get back to baseline but not below.
I’m not convinced that the concept phrased thus would have the same traction. Still, I love this way of looking at it, like I love much of Ward’s POV on the world.
I've also found that the term can be used to describe anything. Some folks would think of anything that isn't "shiny new framework" as tech debt. Some folks think of unsupported features as tech debt. Some folks think that the 2 million line monolithic code base producing billions of profit per year is tech debt.
After seeing a few too many tech debt reduction programs yield even more tech debt than they started with... I simply don't buy retrospective arguments any more. Decide what is acceptable/unacceptable at design time, don't strangle yourself on it after the fact.
Totally agree with that, but I don't think regret is warranted. The power of "technical debt" is that it was actually catchy enough to get a foothold with the MBAs and pointy hairs. That alone is a victory. Any sufficiently good idea with a catchy meme is subject to cargo culting and abuse. We need look no further than The Agile Manifesto to see how thoroughly any well-summarized wisdom, drawn from a well of deep expertise, lovingly word-smithed with the utmost clarity, can be abused and twisted into a hideous monstrosity that is, in fact, the complete opposite of the original intent.
Another problem with the analogy is that you can meaningfully make a $0.01 payment on your debt. You can pick any arbitrary percentage of your debt and pay it off right now, if you have the money to do so. Programming tasks are not only more (unpredictably) quantized than that, they're usually Sisyphean: if you do a little but don't finish, you've wasted the time you spent because the boulder rolls back down as soon as you stop pushing.
> I worked with Ward Cunningham for about a year, and he said once that he regretted coining the phrase “technical debt.” He said it allowed people to think of the debt in a bottomless way: once you’ve accumulated some, why not a little more? After all, the first little bit didn’t hurt us, did it?
I suspect that at the foundational level of this metaphor, the true problem is that some/most people treat financial debt the same, until they're evicted and the car has been repossessed and they've got a warrant out for their failure to show in court.
I want to be wrong about that. Someone tell me I'm wrong.
> He said it allowed people to think of the debt in a bottomless way: once you’ve accumulated some, why not a little more? After all, the first little bit didn’t hurt us, did it?
Isn't this exactly how people mismanage financial debt? If anything it shows the analogy is a good one.
> The end result of this thinking is the feature factory
I'm not sure how relevant this is, but a feature factory is the result of people contracting software development, and measuring it by features; nothing more.
Any other characteristic is a consequence, not a cause.
That's fantastic. I have been lucky enough to cross paths with Ward Cunningham a couple of times and I am always struck by his insight.
Kellan Elliot-McCrae has a similar take on technical debt. In his view there is very little technical debt as traditionally defined - an intentional decision to take a shortcut now that we remediate later.
Instead, "tech debt" is typically a label applied to code that makes developers sad because it resists change. Kellan breaks it down further in this article.
Don't forget people use ambiguity as a tool all the time.
Politicians use words like "justice" or "freedom" to create common ground with little controversy even when they define the term in a way diametrically opposed to their constituents.
I think it can be the same with "tech debt".
I have a friend who figures when he sells his house it will be a tear-down, so he has all kinds of "house tech debt" that he just manages to live with until he literally moves on. it basically means "I don't care about fixing that" or "I'm not going to fix that ever".
I agree with the author of the article that the metaphor is actually very fitting.
That said, I think Ward Cunningham's view is also correct in the context of how debt is viewed today. That said, historically, debt has been regarded as something which was bad for the borrower and only good for the lender.
The distortion likely came about because of reserve bank near-0% interest rate policies enabled by unlimited 'money printing'. Once reserve banks started offering near-0% interest rate loans, private banks found that they could still make big profits by making loans to people on very low margins like 2% to 5% interest rates (since they could themselves borrow upstream at 0%)... But these rates are impossibly low if you think about it. Would any private citizen in their right mind loan their own hard-earned money to other people for 5% interest per year? Let alone while knowing that inflation is almost 5%? Even ignoring inflation which entirely cancels out all the profit, nominally, it barely even covers the risk of the borrower stealing the money and leaving the country... Today, private lending doesn't make sense from the lender's perspective, even when you ignore inflation. Direct lending of one's own money today only makes sense for very risky short term loans with unethically high interest rates (loan sharks).
Anyway, to get back to the point; low interest rates brought on by reserve bank manipulation are unnatural; they made the deal unnaturally good for the borrower (at the expense of the average citizen). Historically, debt was in fact correctly perceived as dangerous for the borrower.
Technical uncovered short position. Nothing wrong with taking a short position on a technical aspect of the project/product and taking the premium right now - so long as you hedge your bets. Otherwise you might have the contract assigned and go bankrupt, or fail to deliver the asset promised and lose everything. There's a reason purposefully taking uncovered short positions is illegal in most developed markets...
This is a nice but very long exploration of the tech debt metaphor, raising several excellent points. I especially like comparing it with the business uses of actual debt.
The only thing I think I'd add to it is that like actual debt, a lot of people do not behave sensibly with tech debt. One of my big tests in any new job is the first time a product manager wants to put something on credit. E.g., "We have to add feature X right now so we can land a big client. Can we cut corners to get this out the door? We'll sort out the mess later."
Despite things like this making my eyelid twitch, I'll always tell a new product manager yes the first time they ask this. But then I watch carefully to see if they're conscientious about paying down the debt. Some of them are great about it, prioritizing the deferred work. Others, though, always have a next emergency. But in my view if it's always an emergency it never is, and so I never again trust them with the tech-debt credit card.
Tbh, cutting corners to land new revenue, if it's sufficiently big, sounds like the prime reason to take on tech debt. It's arguably just like a loan to make a new factory line to expand production for new sales or whatever.
For sure, if it's a small client or far from a sure thing, then yeah it's bad. Like anything, a judgement call about where the cost benefit ratio lies.
I like that litmus test. Another thing I notice is organizations where PMs are assigned to projects as they come up. Meaning, "please cut these corners so I can launch sooner, get all the credit, then move on."
In this case obviously the PM does not have to deal with the fallout, and then the next guy says, "I know this code base is tough, it wasn't by doing, please just try hard and get this feature out"
The other big things I watch for is how much is shipping on time valued, is that the only metric of success? Further, when ROI is calculated, is the return ever actually factored in?
Good engineers don’t create as much tech debt in the first place, or if they do it’s straight-forward code that’s relatively easy to refactor. The #1 fix to prevent most serious tech debt and also get features done quickly is the quality of your engineers (or yourself if you’re the one coding). Someone knowledgeable with several completed projects and up-to-date knowledge should create the codebase.
Also it depends a lot on what stage your project is in. If you have zero customers or money coming in, your focus should be on creating a working product and getting customers. That means zero tests for now, just a working product. It will also more quickly validate if you’re working on the right thing or not, or if you need to pivot.
One problem I see is when engineers want to solve the tech debt problem before even proving the product should exist. No, first establish the demand, get real cash flow, then start focusing on tech debt.
If you are an entrepreneur then tech debt is literally the last of your concerns. If you grow enough where it is then it’s a good problem to have - the biggest problem is typically not enough customers, not too much tech debt.
On the other hand if you are working at Google, and know for a fact thousands or millions of people will use your code, then you should “lock it down” right at the beginning, have all the testing upfront, good documentation, etc.
I asked ChatGPT to explain this quote to me like I'm a five year old who understands Finance at a B.S. level - here's what it said (pretty good IMHO):
Alright, little finance whiz, let's break it down for you. Imagine you have some money, and you can use it to buy something called an "option." An option is like a special ticket that gives you the right to do something later, but you don't have to do it if you don't want to.
Now, in the quote, instead of money and options, we're talking about computer code. When people write code, sometimes they write it in a way that's not very good. We call this "bad code." It's like having a sloppy and messy way of writing instructions for a computer.
But here's the clever part: good code can be like a special kind of option for the future. It means you have the choice to make things better later on. It's like having a ticket that allows you to improve your code and fix any problems.
Now, when code is really bad, it's like not using that special ticket. It's like not taking advantage of the chance to make things better. So, when we say bad code is an "unhedged call option," it means you're not using that ticket and missing out on the opportunity to make things right. It's like not taking the option and potentially causing more problems down the road.
2. at some point, you ought to repay the debt by giving up the same amount of cash
3. until you do, you have to spend a steady trickle of cash servicing the debt
In the technical debt metaphor, cash stands for development effort. But:
1. taking on technical debt doesn't give you a load of development effort out of nowhere (i suppose you could say that shipping what should be a three week feature in two weeks is like getting a week of effort from nowhere, but that seems dubious to me - you haven't shipped the same feature!)
2. repaying technical debt generally takes more work than it saved, because by the time you repay it, it's infected other code that was written afterwards BUT sometimes you end up being able to delete the whole thing, because the feature was retired or fundamentally rewritten, in which case you don't need to repay it at all!
3. sometimes, existing technical debt requires no extra work at all (if it's in a part of the codebase you aren't touching), but if it does, it's not a constant amount, it's proportional to the amount of work you are doing on that code
So it doesn't seem like a brilliant metaphor, really.
Perhaps it's more like cleaning your bike chain after a ride through the mud. If you don't do it, it saves you some time today. But every time you ride your bike again, it's more effort to pedal, and it's wearing your chain out faster.
My problem with the entire technical debt metaphor is that the interest payments are invisible.
On an accounting sheet I can see my interest rate and how much I'm paying monthly and make decisions. With technical debt, it's all about people time, and people time is a sunk cost to your finance department.
I think this is close, but I'd go even further and say that the problem is that with real debt anyone can see the money in black and white, they require no special training to be able to understand real debt and read the numbers off an account summary. There's not much room for interpretation there.
With tech debt, you can ask several engineers and get very different answers about how much tech debt there is on a particular project. It's not well defined, subject to interpretation, and so doesn't fit well with management wanting quantify the objective value of doing something. I think this is the real reason it's often disregarded.
It requires a degree of trust from management to the engineers to properly address, and that trust can be abused. All sides are aware of this and I'm sure I'm not the only one that has used tech debt as an excuse for some minor padding here and there.
I quite like the metaphor, but the author doesn't know how "debt-to-income" (DTI) is calculated. They insist that DTI is a silly concept and instead propose "interest-expense-to-income ratio." They are under the impression that DTI = total principle / income. This is false.
DTI is total debt servicing cost per unit time / income per unit time. The numerator and denominator do not have mismatched units, like the author claims.
What's more, the author's proposed replacement measure--an interest-expense-to-income ratio--is quite silly. By only considering interest expense rather than the total cost to service debts, the measure becomes worthless as a means of estimating the capacity to take on additional debt. If you were to have debts that, despite being interest-free, were large enough for payments toward principle alone to completely consume your income, then you have zero capacity to take on additional debt.
The author also proposed that a bank/lender is to a borrower managing financial debt what a CEO is to an engineering team managing technical debt. They say it without conviction, admittedly, but it is another quite absurd notion. Per the author's metaphor, a lender is incentivized to maximize interest income over the lifetime of a given debt (ignoring rising-rate environments); put differently, prepayment is to a lender's detriment. CEOs very much benefit from prepayment of technical debt. It's a very poor comparison.
I've been trying to think this way about replacing my primary computing hardware. I hate my 2019 intel MBP, but it doesn't slow me down in a way where buying a new one would make me more money, not yet. It would be nice if the fans didn't spin up just to run xcode, but whatever. If I was running arbitrary docker instances for clients and didn't have an issued M1 max with 32gb or more of ram && by buying a new one I could either do more work or complete work faster, then the $5k on a new laptop would be a no-brainer. I'd have hit a wall, the other side of which has greener grass.
At my last job, we were refactoring a bunch of Angular 1.x code for a variety of reasons. It took way way more time than anyone was anticipating, and it was tech debt that had low interest and probably shouldn't have been paid off much earlier than it was. People had chipped away at some components gradually over the years, much like mortgage payments, but after Angular 1.x fully reached EOL, and (imo) we entered a new level of efficiency with build tools, that interest rate started increasing.
I think tech debt can be a useful analogy in software development. We use the term every now and then to point out pieces of code that we want to rewrite.
However, we should not stretch the analogy. I think the author goes way too far. Talking about interest rates, debt ceilings, and ratios doesn’t make sense.
Besides, I'll comment on some of the financial claims:
Debt doesn’t necessarily need to be payed back. I guess most debt is never payed back because there’s are useful projects behind it. If some software is generating millions of profit, should we then pay back all its debt? Maybe it sufficient to just maintain the software a bit a go home early.
Calling a family stupid because they take a loan to go to Disneyland is a very narrow view. Maybe the utility is much higher than the said interest because the family needs a couple of days together (for whatever reasons the economics professor likes to ignore).
> Debt is a drain on your revenues; the thing you did to incur the debt is a boost to your revenues; if you take too long to pay back the debt, it's an overall loss.
> CFOs can calculate that. Engineers don't like to.
Engineers don't get to, in many cases. It's often the managers steering the ship at full pelt.
The longer I am in this industry the more I am disappointed about the fact that instead of using disciplined, quantifiable processes we are more and more in the realm of poetry with "analogies" or "metaphors".
This kind of language - while sounding deceptively smart - does not help in any decision making because the terms are neither measurable nor actionable... Just meaningless.
What we need are answers to questions like: how do we measure maintainability of software systems? How do we compare solutions and select them? How do we decide on what investment in making the software better is worth pursuing?
Is "tech debt" even something that can be measured and actioned upon? How do we know if our changes to the software made it bigger or smaller? How do we know its impact on the bottom line?
It's because measuring those things is impossible. It's not like people haven't tried - look up cyclomatic complexity for example.
But programming is more like product design or urban planning than structural engineering or construction.
There's no formula for maintainability or technical debt in the same way that there's no formula for the best town design.
That doesn't mean that all towns are equal, or that we can't say anything about urban planning. It just means you can rarely make concrete rules about it.
I really enjoy the process of analogy maximalism. You can gain insight to an unfamiliar process by taking analogies too far. Asking “what’s the analogue of this” in another space with similarities can produce productive insights even if the analogy is overall not great.
One very similarly finance-oriented comparison that I like to make is that every line code is a liability, in the financial sense of that word[1]: that's what's on the right side of your balance sheet, which enables your assets: that is your product.
Like there are many ways to finance your business, there are many ways to make the same product, from coding it from scratch yourself (which ranges from “from quick and dirty” to “using formal methods”) to customizing a open-source foundation, or even a third party's white-label product. Which one is better completely depends on the situation (like with equity vs debt).
[1]:in finance, “liability” isn't “bad”, debt is a liability, but so is equity, and even profit is a liability!
I think tech debt isn’t a great analogy for most situations. Usually, somebody did something quick, over architected something or otherwise didn’t do a great job - or did a great job for the time but is now terrible for whatever needs to be done now. Alternately these situations never play out so no cost is ever incurred. The debt “payment” cannot be calculated up front so the analogy falls pretty flat in most cases.
True technical debt analogies are more like introducing something that increases build time on a large team since this is paid continuously.
We just need to accept that in software, sometimes stuff needs to be done that doesn’t have an obvious end user benefit in order to keep the code base viable.
I am definitely not paying off my low interest rate mortgage faster than I have to. I did however prioritize paying down 7% interest student loans over saving.
I think one of the problems with tech debt as a metaphor is that generally with financial debt the person or entity who can reap the benefit or suffer the consequences of that debt are one and the same, and they are making a decision with both of those scenarios in mind. The CFO is the sole person "doing the math" on accruing debt. The person who get to live in the house is the one taking on mortgage debt.
In tech debt though, that is split into two groups:
- "the business" concretely reap the benefit of accruing tech debt (release faster = more profit), only abstractly feeling the consequences (developers are maybe slower and maybe more miserable than they should be)
- developers suffer the consequences directly (working with badly maintained code that you don't have leeway to resolve is soul crushing), while only abstractly reaping any benefit[1] (maybe the business profits more which maybe gives them more leeway for maybe a better pay rise than they would have otherwise gotten)
The concrete feelings are obvious, the abstract ones are all arguable because you don't live the opposite (maybe this feature would have always taken this long, maybe the company would have always been able to afford that pay rise), and so are easy to ignore.
So then, unlike financial debt, the decision whether or not to accrue tech debt is ugly tension between two groups who don't really understand or have empathy for each others motivation. The business would always prefer you go as fast as you can, and developers would always prefer they work with code that isn't miserable to work with.
Attempts to solve this are pretty mixed in my experience, and generally the business wins. Which is I think, where most people's negative feelings on the phrase "tech debt" comes from.
[1] the obvious counterpoint here is startups and other jobs where you get stock options etc. I have only worked in that scenario once, and my company was a subsidiary of a much larger one, so our ability to move the needle on stock value was pretty negligible. It may be in scenarios where you really can make a difference tech debt decisions are more harmonious. Interested to hear people's experiences.
Every time some feature is added, it's like putting some weights into the backpack of >>every<< developer that will interact with that part of the system in future. Some actions add more, others less, but you have to be careful. Too much weights will slow down the team/company to a point where no meaningful work can be done anymore. To reach a goal you have to add tech debt, but some feature add way more than others. Ideally tech debt is accumulated in isolated areas that do not interfere with other parts of the system.
> The advice that you should "always buy the biggest home you can afford" is often perversely accurate, especially if you believe property values will keep going up.
Ehhhhhhhh too much of that return goes straight to Consumption instead of your bank account. If we’re going for Max Returns, buy the biggest home you can… and rent it out as you live in a shoebox. ;)
I have some thoughts on this also. The main thing is that tech debt does not capture the ongoing costs – you only pay interest when there is a principal, and for all debt, you can pay the principal off.
These days I get riled up about the word "technical" and the general absence of risk in these conversations about "debt". I wrote a long post [1], which basically says:
1. The "Technical" word pigeonholes responsibility to the "technical" people. This creates all manner of problems (management, strategy, resource allocation etc.). It ought to be seen as "Software" debt, because the whole software company owns it.
2. Software debt packages risk. We need better mental models of that risk.
- This perception is commonly muddied by personal bias---how we think of finances and debt in our daily lives.
- However, it requires thinking like a strategist and/or economist (much more abstract, nuanced terms). The trouble is that the "debt" is rooted in complexity, which, like rocket mass, is inevitable. And we abhor it because solving for complexity is like solving for rocket mass; requires recursive tree-networked thinking.
- The debt is also inevitable because we want some complexity (rocket mass). It's just that it needs be the exact kind we need, which choice-making is difficult.
- This sort of complexity-debt always compounds and each decision to add or remove items from any part of the system changes the principal and the rate of interest and the repayment terms.
- It is layered because software parts compose into software "stacks" and hierarchies, and each part mutates/evolves up and down the towers.
- It is networked. Because software itself is networked. Small local changes can turn into literal chain reactions of events. The meltdown of Knight Capital stands out starkly as an example of unmitigated, un-hedged software debt.
Ultimately, the "debt" part of "software debt" is better seen as if it were a complex opaque financial derivative. Unchecked creation of software debt is exactly analogous to how the 2008 financial crisis came to be. It's all composed of "simple" debt.
Much as I dislike all this doom-speak, I have to acknowledge it is material, and to side with Andy Grove. Only the paranoid survive.
The only real hedge we have is the creativity and intelligence of our people.
[+] [-] sonofhans|2 years ago|reply
The end result of this thinking is the feature factory, where a company only ever builds new features, usually to attract new customers. Necessary refactors are called “tech debt” and left to pile up. Yes, this is just another view of bad management, but still, Ward thought that the metaphor afforded it too easily.
He said he wished instead that he’d coined “opportunity,” as in, producing or consuming it. Good practices produce opportunity. Opportunity can then be consumed in order to meet certain short-term goals.
So it flips the baseline. Rather than having a baseline of quality then dipping below it into tech debt, you’d produce opportunity to put you above the baseline. Once you have this opportunity, you consume it to get back to baseline but not below.
I’m not convinced that the concept phrased thus would have the same traction. Still, I love this way of looking at it, like I love much of Ward’s POV on the world.
[+] [-] lumost|2 years ago|reply
After seeing a few too many tech debt reduction programs yield even more tech debt than they started with... I simply don't buy retrospective arguments any more. Decide what is acceptable/unacceptable at design time, don't strangle yourself on it after the fact.
[+] [-] dasil003|2 years ago|reply
[+] [-] commandlinefan|2 years ago|reply
[+] [-] NoMoreNicksLeft|2 years ago|reply
I suspect that at the foundational level of this metaphor, the true problem is that some/most people treat financial debt the same, until they're evicted and the car has been repossessed and they've got a warrant out for their failure to show in court.
I want to be wrong about that. Someone tell me I'm wrong.
[+] [-] brianpan|2 years ago|reply
Isn't this exactly how people mismanage financial debt? If anything it shows the analogy is a good one.
[+] [-] marcosdumay|2 years ago|reply
I'm not sure how relevant this is, but a feature factory is the result of people contracting software development, and measuring it by features; nothing more.
Any other characteristic is a consequence, not a cause.
[+] [-] neilk|2 years ago|reply
Kellan Elliot-McCrae has a similar take on technical debt. In his view there is very little technical debt as traditionally defined - an intentional decision to take a shortcut now that we remediate later.
Instead, "tech debt" is typically a label applied to code that makes developers sad because it resists change. Kellan breaks it down further in this article.
https://kellanem.com/notes/towards-an-understanding-of-techn...
[+] [-] m463|2 years ago|reply
Politicians use words like "justice" or "freedom" to create common ground with little controversy even when they define the term in a way diametrically opposed to their constituents.
I think it can be the same with "tech debt".
I have a friend who figures when he sells his house it will be a tear-down, so he has all kinds of "house tech debt" that he just manages to live with until he literally moves on. it basically means "I don't care about fixing that" or "I'm not going to fix that ever".
[+] [-] jongjong|2 years ago|reply
That said, I think Ward Cunningham's view is also correct in the context of how debt is viewed today. That said, historically, debt has been regarded as something which was bad for the borrower and only good for the lender.
The distortion likely came about because of reserve bank near-0% interest rate policies enabled by unlimited 'money printing'. Once reserve banks started offering near-0% interest rate loans, private banks found that they could still make big profits by making loans to people on very low margins like 2% to 5% interest rates (since they could themselves borrow upstream at 0%)... But these rates are impossibly low if you think about it. Would any private citizen in their right mind loan their own hard-earned money to other people for 5% interest per year? Let alone while knowing that inflation is almost 5%? Even ignoring inflation which entirely cancels out all the profit, nominally, it barely even covers the risk of the borrower stealing the money and leaving the country... Today, private lending doesn't make sense from the lender's perspective, even when you ignore inflation. Direct lending of one's own money today only makes sense for very risky short term loans with unethically high interest rates (loan sharks).
Anyway, to get back to the point; low interest rates brought on by reserve bank manipulation are unnatural; they made the deal unnaturally good for the borrower (at the expense of the average citizen). Historically, debt was in fact correctly perceived as dangerous for the borrower.
[+] [-] justinjlynn|2 years ago|reply
[+] [-] JJMcJ|2 years ago|reply
[+] [-] divbzero|2 years ago|reply
[+] [-] Procrastes|2 years ago|reply
[+] [-] xnx|2 years ago|reply
[+] [-] wpietri|2 years ago|reply
The only thing I think I'd add to it is that like actual debt, a lot of people do not behave sensibly with tech debt. One of my big tests in any new job is the first time a product manager wants to put something on credit. E.g., "We have to add feature X right now so we can land a big client. Can we cut corners to get this out the door? We'll sort out the mess later."
Despite things like this making my eyelid twitch, I'll always tell a new product manager yes the first time they ask this. But then I watch carefully to see if they're conscientious about paying down the debt. Some of them are great about it, prioritizing the deferred work. Others, though, always have a next emergency. But in my view if it's always an emergency it never is, and so I never again trust them with the tech-debt credit card.
[+] [-] automatic6131|2 years ago|reply
For sure, if it's a small client or far from a sure thing, then yeah it's bad. Like anything, a judgement call about where the cost benefit ratio lies.
[+] [-] seadan83|2 years ago|reply
In this case obviously the PM does not have to deal with the fallout, and then the next guy says, "I know this code base is tough, it wasn't by doing, please just try hard and get this feature out"
The other big things I watch for is how much is shipping on time valued, is that the only metric of success? Further, when ROI is calculated, is the return ever actually factored in?
[+] [-] xyzzy4747|2 years ago|reply
Also it depends a lot on what stage your project is in. If you have zero customers or money coming in, your focus should be on creating a working product and getting customers. That means zero tests for now, just a working product. It will also more quickly validate if you’re working on the right thing or not, or if you need to pivot.
One problem I see is when engineers want to solve the tech debt problem before even proving the product should exist. No, first establish the demand, get real cash flow, then start focusing on tech debt.
If you are an entrepreneur then tech debt is literally the last of your concerns. If you grow enough where it is then it’s a good problem to have - the biggest problem is typically not enough customers, not too much tech debt.
On the other hand if you are working at Google, and know for a fact thousands or millions of people will use your code, then you should “lock it down” right at the beginning, have all the testing upfront, good documentation, etc.
[+] [-] twic|2 years ago|reply
https://www.infoq.com/news/2014/12/call-options-bad-code/
[+] [-] StarlaAtNight|2 years ago|reply
Alright, little finance whiz, let's break it down for you. Imagine you have some money, and you can use it to buy something called an "option." An option is like a special ticket that gives you the right to do something later, but you don't have to do it if you don't want to.
Now, in the quote, instead of money and options, we're talking about computer code. When people write code, sometimes they write it in a way that's not very good. We call this "bad code." It's like having a sloppy and messy way of writing instructions for a computer.
But here's the clever part: good code can be like a special kind of option for the future. It means you have the choice to make things better later on. It's like having a ticket that allows you to improve your code and fix any problems.
Now, when code is really bad, it's like not using that special ticket. It's like not taking advantage of the chance to make things better. So, when we say bad code is an "unhedged call option," it means you're not using that ticket and missing out on the opportunity to make things right. It's like not taking the option and potentially causing more problems down the road.
[+] [-] cannonpalms|2 years ago|reply
[+] [-] klysm|2 years ago|reply
[+] [-] twic|2 years ago|reply
1. you take on debt to get hold of some cash
2. at some point, you ought to repay the debt by giving up the same amount of cash
3. until you do, you have to spend a steady trickle of cash servicing the debt
In the technical debt metaphor, cash stands for development effort. But:
1. taking on technical debt doesn't give you a load of development effort out of nowhere (i suppose you could say that shipping what should be a three week feature in two weeks is like getting a week of effort from nowhere, but that seems dubious to me - you haven't shipped the same feature!)
2. repaying technical debt generally takes more work than it saved, because by the time you repay it, it's infected other code that was written afterwards BUT sometimes you end up being able to delete the whole thing, because the feature was retired or fundamentally rewritten, in which case you don't need to repay it at all!
3. sometimes, existing technical debt requires no extra work at all (if it's in a part of the codebase you aren't touching), but if it does, it's not a constant amount, it's proportional to the amount of work you are doing on that code
So it doesn't seem like a brilliant metaphor, really.
Perhaps it's more like cleaning your bike chain after a ride through the mud. If you don't do it, it saves you some time today. But every time you ride your bike again, it's more effort to pedal, and it's wearing your chain out faster.
[+] [-] c-linkage|2 years ago|reply
On an accounting sheet I can see my interest rate and how much I'm paying monthly and make decisions. With technical debt, it's all about people time, and people time is a sunk cost to your finance department.
[+] [-] smif|2 years ago|reply
With tech debt, you can ask several engineers and get very different answers about how much tech debt there is on a particular project. It's not well defined, subject to interpretation, and so doesn't fit well with management wanting quantify the objective value of doing something. I think this is the real reason it's often disregarded.
It requires a degree of trust from management to the engineers to properly address, and that trust can be abused. All sides are aware of this and I'm sure I'm not the only one that has used tech debt as an excuse for some minor padding here and there.
[+] [-] cannonpalms|2 years ago|reply
DTI is total debt servicing cost per unit time / income per unit time. The numerator and denominator do not have mismatched units, like the author claims.
What's more, the author's proposed replacement measure--an interest-expense-to-income ratio--is quite silly. By only considering interest expense rather than the total cost to service debts, the measure becomes worthless as a means of estimating the capacity to take on additional debt. If you were to have debts that, despite being interest-free, were large enough for payments toward principle alone to completely consume your income, then you have zero capacity to take on additional debt.
The author also proposed that a bank/lender is to a borrower managing financial debt what a CEO is to an engineering team managing technical debt. They say it without conviction, admittedly, but it is another quite absurd notion. Per the author's metaphor, a lender is incentivized to maximize interest income over the lifetime of a given debt (ignoring rising-rate environments); put differently, prepayment is to a lender's detriment. CEOs very much benefit from prepayment of technical debt. It's a very poor comparison.
[+] [-] brailsafe|2 years ago|reply
At my last job, we were refactoring a bunch of Angular 1.x code for a variety of reasons. It took way way more time than anyone was anticipating, and it was tech debt that had low interest and probably shouldn't have been paid off much earlier than it was. People had chipped away at some components gradually over the years, much like mortgage payments, but after Angular 1.x fully reached EOL, and (imo) we entered a new level of efficiency with build tools, that interest rate started increasing.
[+] [-] mo_42|2 years ago|reply
However, we should not stretch the analogy. I think the author goes way too far. Talking about interest rates, debt ceilings, and ratios doesn’t make sense.
Besides, I'll comment on some of the financial claims:
Debt doesn’t necessarily need to be payed back. I guess most debt is never payed back because there’s are useful projects behind it. If some software is generating millions of profit, should we then pay back all its debt? Maybe it sufficient to just maintain the software a bit a go home early.
Calling a family stupid because they take a loan to go to Disneyland is a very narrow view. Maybe the utility is much higher than the said interest because the family needs a couple of days together (for whatever reasons the economics professor likes to ignore).
[+] [-] dryanau|2 years ago|reply
> CFOs can calculate that. Engineers don't like to.
Engineers don't get to, in many cases. It's often the managers steering the ship at full pelt.
[+] [-] mkleczek|2 years ago|reply
This kind of language - while sounding deceptively smart - does not help in any decision making because the terms are neither measurable nor actionable... Just meaningless.
What we need are answers to questions like: how do we measure maintainability of software systems? How do we compare solutions and select them? How do we decide on what investment in making the software better is worth pursuing?
Is "tech debt" even something that can be measured and actioned upon? How do we know if our changes to the software made it bigger or smaller? How do we know its impact on the bottom line?
[+] [-] IshKebab|2 years ago|reply
But programming is more like product design or urban planning than structural engineering or construction.
There's no formula for maintainability or technical debt in the same way that there's no formula for the best town design.
That doesn't mean that all towns are equal, or that we can't say anything about urban planning. It just means you can rarely make concrete rules about it.
[+] [-] barrysteve|2 years ago|reply
Everybody knows in the whispers of their soul that an empirically mapped out programming culture, is a dead one.
I can see how to tie together all the publicly available knowledge on programming into truthfully-easy to understand education material.
People like Casey Muratori are selling the game of programming out from the bottom up. (and good for him).
Why do it when we have to sell our skills today to put bread on the table?
[+] [-] klysm|2 years ago|reply
[+] [-] littlestymaar|2 years ago|reply
Like there are many ways to finance your business, there are many ways to make the same product, from coding it from scratch yourself (which ranges from “from quick and dirty” to “using formal methods”) to customizing a open-source foundation, or even a third party's white-label product. Which one is better completely depends on the situation (like with equity vs debt).
[1]:in finance, “liability” isn't “bad”, debt is a liability, but so is equity, and even profit is a liability!
[+] [-] osigurdson|2 years ago|reply
True technical debt analogies are more like introducing something that increases build time on a large team since this is paid continuously.
We just need to accept that in software, sometimes stuff needs to be done that doesn’t have an obvious end user benefit in order to keep the code base viable.
[+] [-] mensetmanusman|2 years ago|reply
Have any engineers successfully fought against the urge to pay off debt quickly?
Can't help but pay off my house faster than the mortgage...
[+] [-] wffurr|2 years ago|reply
[+] [-] cannonpalms|2 years ago|reply
[+] [-] SCdF|2 years ago|reply
In tech debt though, that is split into two groups:
- "the business" concretely reap the benefit of accruing tech debt (release faster = more profit), only abstractly feeling the consequences (developers are maybe slower and maybe more miserable than they should be)
- developers suffer the consequences directly (working with badly maintained code that you don't have leeway to resolve is soul crushing), while only abstractly reaping any benefit[1] (maybe the business profits more which maybe gives them more leeway for maybe a better pay rise than they would have otherwise gotten)
The concrete feelings are obvious, the abstract ones are all arguable because you don't live the opposite (maybe this feature would have always taken this long, maybe the company would have always been able to afford that pay rise), and so are easy to ignore.
So then, unlike financial debt, the decision whether or not to accrue tech debt is ugly tension between two groups who don't really understand or have empathy for each others motivation. The business would always prefer you go as fast as you can, and developers would always prefer they work with code that isn't miserable to work with.
Attempts to solve this are pretty mixed in my experience, and generally the business wins. Which is I think, where most people's negative feelings on the phrase "tech debt" comes from.
[1] the obvious counterpoint here is startups and other jobs where you get stock options etc. I have only worked in that scenario once, and my company was a subsidiary of a much larger one, so our ability to move the needle on stock value was pretty negligible. It may be in scenarios where you really can make a difference tech debt decisions are more harmonious. Interested to hear people's experiences.
[+] [-] thibran|2 years ago|reply
Every time some feature is added, it's like putting some weights into the backpack of >>every<< developer that will interact with that part of the system in future. Some actions add more, others less, but you have to be careful. Too much weights will slow down the team/company to a point where no meaningful work can be done anymore. To reach a goal you have to add tech debt, but some feature add way more than others. Ideally tech debt is accumulated in isolated areas that do not interfere with other parts of the system.
[+] [-] sclarisse|2 years ago|reply
Ehhhhhhhh too much of that return goes straight to Consumption instead of your bank account. If we’re going for Max Returns, buy the biggest home you can… and rent it out as you live in a shoebox. ;)
(Or buy smaller homes, to diversify.)
[+] [-] madsbuch|2 years ago|reply
https://www.madsbuch.com/tech-debt-tax/
[+] [-] adityaathalye|2 years ago|reply
1. The "Technical" word pigeonholes responsibility to the "technical" people. This creates all manner of problems (management, strategy, resource allocation etc.). It ought to be seen as "Software" debt, because the whole software company owns it.
2. Software debt packages risk. We need better mental models of that risk.
- This perception is commonly muddied by personal bias---how we think of finances and debt in our daily lives.
- However, it requires thinking like a strategist and/or economist (much more abstract, nuanced terms). The trouble is that the "debt" is rooted in complexity, which, like rocket mass, is inevitable. And we abhor it because solving for complexity is like solving for rocket mass; requires recursive tree-networked thinking.
- The debt is also inevitable because we want some complexity (rocket mass). It's just that it needs be the exact kind we need, which choice-making is difficult.
- This sort of complexity-debt always compounds and each decision to add or remove items from any part of the system changes the principal and the rate of interest and the repayment terms.
- It is layered because software parts compose into software "stacks" and hierarchies, and each part mutates/evolves up and down the towers.
- It is networked. Because software itself is networked. Small local changes can turn into literal chain reactions of events. The meltdown of Knight Capital stands out starkly as an example of unmitigated, un-hedged software debt.
Ultimately, the "debt" part of "software debt" is better seen as if it were a complex opaque financial derivative. Unchecked creation of software debt is exactly analogous to how the 2008 financial crisis came to be. It's all composed of "simple" debt.
Much as I dislike all this doom-speak, I have to acknowledge it is material, and to side with Andy Grove. Only the paranoid survive.
The only real hedge we have is the creativity and intelligence of our people.
More at my blog post here: https://www.evalapply.org/posts/software-debt/