The best analogy for technical debt is debt - that is where it got the name from! Just like financial debt, technical debt is not necessary a bad thing, but a tool - and something to manage, control and track. And just like financial debt, taking out too much technical debt without paying it back can crush you.
There is nothing wrong with taking out a mortgage (and thus getting into debt) to buy a house - you just need to understand how to pay it off. Similarly, if you start a startup trying to find product-market fit before running out of money, there is nothing wrong taking on technical debt to do so, as long as you understand what you are doing.
The problem with this analogy is you don't necessarily take on technical debt when you make your technical decisions. Technical decisions only become debt when you have to revisit those decisions. You don't pay interest on debt over time. You pay interest whenever you build upon or modify the flawed code.
You can write the shittiest spaghetti code in the world, and if you never have to build upon - or touch it again - you took on zero technical debt.
In comparison, if you write just slightly flawed design, but build out your complete featureset based upon that flawed design, you could have mountains of technical debt.
I think a better analogy is building a structure. If your code is foundational, you better get that shit right. If you cheap out on a $20 part and have to replace it, but it's just a door knob, that's not too bad. But if it's under your slab on grade foundation you're going to pay thousands to dig it up and fix a $20 part.
The difference though is that financial debt is very easy to measure and quantify but technical debt is not.
I like the Tetris analogy because that game has a type of debt that anyone who has played it can understand, yet is not as easily quantifiable as financial debt.
A monetary metaphor for technical debt implies a freedom to the order of addressing technical debt that is deceptive. This comes from money's fungible nature: if you have many debts, you can pay off whichever debt you want and you can pay it off in parts.
I think this metaphor does a good job of capturing the path-dependant nature of debt. How the size of each individual debt sits in the shadow of the code that relies on the flawed code. Understanding that there's the work of fixing technical debt and the work of getting to the place where you can fix technical debt feels more clearly communicated by tetris than by financial debt.
Financial debt is a good analogy, but there is a crucial difference: technical debt is not fungible.
Cleaning up one kind of issue in your code doesn't affect other kinds of issues, and you can end up with fundamental architectural problems that no amount of testing or clean up can compensate for. You can handle some issues incrementally (eg adding tests), but some issues are going to be so fundamental to your system that you can only handle them by making a lot of changes all at once.
In this analogy, game development is like taking on crippling amounts of debt, declaring bankruptcy, and then starting a new company to do it all over again.
And just like real debt, you can just walk away from it at any time with no obligation right, not even on your credit rating? Just look at the debt and say "don't want you no more" and the debt says "aw shucks. Guess you don't feel the benefit of paying me. I can understand. So all right.
I won't complain.", and the debt goes and disappears, down some dark alley with a bottle of scotch, no debt collectors ever hound you about it, and you never hear from the debt again.
That kind of debt, right?
But wait there's more! I forgot to mention that even if you walk away you get to keep what you bought on credit, without any further payment of any kind and it continues working in its current state, forever - you just can't improve or renovate it if you walk away from the debt.¹
That kind of debt, right? If so then perfect analogy.
-
¹ literal lie though, yes you can. you can totally still improve it real quick. I'm afraid I'll have to add $150,000 to your technical debt though, which you can walk away from any time. still want this real quick $50 change though? It might be $50 but it's $150,000 in debt though.
In general, I'd agree with that assessment, but the debt-based metaphor also reaches its limits in a couple of cases.
One of which is that it is often really hard to quantify, but that does not seem to stop many non-technical manager types from trying to treat it like financial debt nontheless.
Another one is that unlike financial debt, which should be controlled by various organization-internal mechanisms, tech debt is often not something management is conscious about (at least when it is "created"). I've seen far too many examples of horrible code that can simply be explained with lazyness or incompetence, but I'm pretty sure management never called for a hard to use, unnecessarily complicated API.
Also, if the tech debt is caused by management, it is usually an implicit byproduct of unrealistic time constraints, and I'm pretty sure in those cases they would often choose find another solution too if they were conscious about how bad the problem they're creating really is.
Edit: Either that, or their incentives are way off because they don't have to deal with the consequences. Which is also the real cause why financial debt is usually strictly controlled.
The old 25% rule (don't take a mortgage unless it is no more than 25% of your income) is ignored all the time. My mortgage was right at that, and I generally have never had trouble coming up with it. If I was doing 50-70% like some of my California friends I'd be as nervous as a rat at a cat farm. So I think you have to set some reasonable amount of technical debt as you say. Some issue simply dissolve, others get worse as far as the debt goes. Sometimes the business goes in a different direction and more dissolves. Other times maybe a big deal comes in for one of your products and you realize it might not be as easy to update for new needs (and $$ of income in particular) so you don't want to let it build up too much.
The problem to me is this covers your language choice as a debt. You are literally borrowing against the knowledge in the standard library of your language choice. You may have to leave standard someday based on growth or success.
Most of what people call debt, though, is really just comprises. Which works, to me, as you can just say the code is too compromised. :)
Another thing worth noting is that company success doesn't mean you're more easily able to pay off the debt like you would your mortgage. In fact the opposite may be true and it may limit future earnings if it bites you in the wrong place.
It's a good analogy, but if this is what it took to get through to your PM what technical debt is, I think you should look for another job, stat. This is a core concept anyone with that kind of power over your work hours should understand deeply already.
>This is a core concept anyone with that kind of power over your work hours should understand deeply already.
If the individual(s) with power over ones work have spent time writing code then they will most likely have an understanding. If they haven't then it often takes analogies of this nature to help them begin to understand what technical debt is and how it has an impact on the future of the product.
In this kind of discussions I read the same two or three positions rehashed over and over again that are highly dependent on the situation(s) the wielder of such opinions has found themselves in previously.
One thing I've never seen properly stated is the difference between technical debt as usually described (building code that is doing the job but might not be as flexible, easy to change or fix or might not account for all corner cases appropriately) and then the kind of debt I've experience more often which is "model debt". In the field of business applications, modeling a problem correctly is 80% of the solution, and new companies usually do that job very poorly. Over time as business experience accumulates, some of those mistakes become evident. For example, how to model the identity of the users of an application, that's where the most mindless decisions I've experienced do the most damage. Let's say you assume the only type of user you're gonna have belongs to "companies" and your customers are companies. Then you discover those companies make heavy use of consultants or contractors, and all of a sudden most of your management tools and UI doesn't quite fit. You can hack it, but you end up with a large slice of your users having to manage 20 different emails to interact with your system. Just an example.
"model debt" is the most expensive and potentially fatal type of debt a new piece of software can incur, and my suggestion is for every new project, focus on building a real good model of what reality looks like before too many other technical calls are made, or you're in for a world of hurt.
I tend use the "Leaning Tower of Pisa" metaphor.
If it leans too much, the tower will fall down.
If it doesn't tilt at all, you won't sell tickets to tourists.
> The analogy with technical debt is that each new fix or development is like a new block coming in, which you need to integrate with the existing code. If you hack it in a quick and dirty way, it’s like leaving holes in the Tetris structure: you’re making life more difficult down the line.
Like with Tetris sometimes you find a block that allows for retirement of a lot of old stuff. But maybe this block never comes. Or maybe it comes only after you papered over the debt and the solution does not work anymore.
It's not the best metaphor on just the technical debt, but to the whole modern corporate governance, which prefers short term profits instead of fixing things for long term gains.
Fully agree. Refactoring (that serves to reduce tech. debt) needs to happen on a recurring basis. It's the 3rd pillar of coding activity, alongside features, and bugfixes.
Technical debt is risk. Just like in financial systems, taking on SOME risk is how you make money, but you need to measure it and minimize it and be prepared for if the risks taken all end unfavorably. This product risk (see also dependency risk) is intertwined with the combined risk of other projects going on, whether they're public relations risk, technical risk, staff risk, etc. and taking on too much risk means you have too many flipped coins in the air to count on them all landing favorably for you, even if they're weighted.
Tech debt is more nuanced than explained by most analogies.
In reality there is a lot of tech debt you can get away for free and never have to pay back. The code can be a mess but the functionality works and doesn't need updating.
Other tech debt can infect and cripple a system if it isn't contained early.
If you demonstrate that you know how to prioritize the most important tech debt then it is easier to convince management to work on it.
The concept of doing more work now to make future easier is universal. Delivering on it is the hard part.
If it never costs you anything, it's just a design decision, not technical debt. Plenty of projects never upgraded C versions, so old C is maybe not technical debt. But plenty of projects are upgrading python versions now, so old python is often technical debt.
Analogies create a false sense of meaning. Nothing new is gained other than an isomorphism. There is no logical transfer of new information because the analogy only works if you already understand both concepts. Additionally, analogies may over simplify concepts but usually people are too enamored by the isomorphism to really see it.
Think about this famous analogy: "Life is like a box of chocolates. You never know what you're gonna get."
I clearly know about how life and a box of chocolates can be random at times. This is dead obvious information to the point of pointlessness. Yet in church or in meetings you see people nod their heads in agreement as if something insightful was said. Here's reality: Nothing insightful was said, the person who was comparing life to a box of chocolates is literally mentally retarded.
Isomorphism can yield eye-opening insights and inspire new behaviors. Drawing connections between similar ideas in different domains can be an enjoyable and creative mental exercise.
>Even if you leave a few holes in, it’s ok if you manage to have compact rows above them that will clear out and allow to fill the holes later. This is similar to technical debt, that is ok to build up if it’s under control and you have a plan to pay it back later.
That's a very low-tier understanding of Tetris. At an intermediate level of play, you'll want to deliberately leave gaps that you could clear at any time, but you choose to wait until it is strategically advantageous to do so.
At an advanced level of play, you'll want to leave oddly-shaped gaps that can only be cleared with a Clever Hack which not everyone is able to understand, let alone perform. (T-Spin)
Similar concepts do exist in programming, they are cynically referred to as "Job Security" but I doubt that the author intended to encourage that sort of behavior.
People talk about technical debt like it accumulates to a point where you can't go on, but as someone who has worked at a company with totally overwhelming, malignant tech debt, teams can and do go on, for some definition of "going on." Don't get me wrong, it is an absolute miserable place to be. It's like a software purgatory, where things "work" but also mysteriously don't work sometimes. Will you be punished for implementing new feature X? Nobody knows--that's for the tech debt monster to decide.
I believe that learning how to identify a team that is drowning in tech debt is a valuable interview skill.
This is an ad for a book on dealing with legacy code. The preview of the book [1] is more useful than the forced Tetris analogy.
Reading the table of contents of the book, it seems to assume everything is done by hand. There are some power tools for dealing with legacy code in C/C++, but I don't know which ones are any good and for what. A book which covered most of them and wasn't a fan piece for one tool would be helpful.
Technical Debt is a term used by non-professionals as a euphemism for their own incompetence. I say this not to cut people down but with all due desire for us to get better at our work.
It's a lot harder for someone to say "I didn't know how to solve this" and much easier to say "It would take longer to solve it the right way." Because of this you should take claims fo "Technical Debt" with serious suspicion -- and given how fuzzy the general concept is and how enabling it is, I think the proper response is to find it useful far more for personal ego management than as a respectable tool for thinking about execution of software projects.
There is no innate conflict between solid decision-making in a software system and execution time. Generalizations take longer but generalizations or lack thereof do not imply sound architecture; this is orthogonal concerns. But solid execution (decoupled components) is a skillset question. In fact if you have the skillset it often takes longer to make a bad decision.
Technical Debt doesn't respect this (i.e. skills/mastery) and is only good for deflecting from our incompetence and thus keeping us from acquiring the necessary skillset.
Implementation technical debt (the code) makes it harder for devs to work in a given service, slows down velocity and increases the risk of bugs, but is at least contained to a given service and can be rewritten as a known quantity.
Architectural technical debt will crush your product or your stack, often quickly.
Technical debt for me means I will have a job fixing it at my current company for many years to come (If I want it).
There will almost always be technical debt to some degree when it comes to software. Nothing is perfect and we always dont have the time to create the perfect fix..and instead need to just create something that works.
I think my favorite analogy for technical debt is uncovered option, which, compared to just technical debt, adds the information that it might or might not be required to pay it back. Of course, to be able to use, your non-coder interlocutor needs to know the relevant vocabulary.
It so happens I’ve been thinking a lot about the debt analogy recently and decided that the simplest improvement is to think of it as an interest-only loan.
Sure, that balloon is just sitting there, but every single day you don’t pay it down, you are still paying interest. It slows you down when it causes confusion, when it makes integration more difficult, and when everyone is afraid to make improvements that might require changes to That Godforsaken Class.
And if instead of paying it down, you decide to add more debt, then the interest payments go up / the drag just gets worse.
And let’s be honest, arguing that tech debt is not bad comes up way more often over adding more than deciding not to start paying down.
Was waiting for the ultimate analogy : Plugin a tetris vertical bar is like a carefully planned ahead refactoring. It's the most effective strategy as it clean out 4 lines of technical debt in a single move.
[+] [-] newbkoder|6 years ago|reply
There is nothing wrong with taking out a mortgage (and thus getting into debt) to buy a house - you just need to understand how to pay it off. Similarly, if you start a startup trying to find product-market fit before running out of money, there is nothing wrong taking on technical debt to do so, as long as you understand what you are doing.
[+] [-] bcrosby95|6 years ago|reply
You can write the shittiest spaghetti code in the world, and if you never have to build upon - or touch it again - you took on zero technical debt.
In comparison, if you write just slightly flawed design, but build out your complete featureset based upon that flawed design, you could have mountains of technical debt.
I think a better analogy is building a structure. If your code is foundational, you better get that shit right. If you cheap out on a $20 part and have to replace it, but it's just a door knob, that's not too bad. But if it's under your slab on grade foundation you're going to pay thousands to dig it up and fix a $20 part.
[+] [-] Ottolay|6 years ago|reply
I like the Tetris analogy because that game has a type of debt that anyone who has played it can understand, yet is not as easily quantifiable as financial debt.
[+] [-] aeturnum|6 years ago|reply
I think this metaphor does a good job of capturing the path-dependant nature of debt. How the size of each individual debt sits in the shadow of the code that relies on the flawed code. Understanding that there's the work of fixing technical debt and the work of getting to the place where you can fix technical debt feels more clearly communicated by tetris than by financial debt.
[+] [-] slumdev|6 years ago|reply
Technical debt is not well understood, and its impact is not easy to measure.
This analogy is probably why so many companies make the (usually wrong) decision regarding technical debt.
[+] [-] tikhonj|6 years ago|reply
Cleaning up one kind of issue in your code doesn't affect other kinds of issues, and you can end up with fundamental architectural problems that no amount of testing or clean up can compensate for. You can handle some issues incrementally (eg adding tests), but some issues are going to be so fundamental to your system that you can only handle them by making a lot of changes all at once.
You can't refinance technical debt!
[+] [-] cylon13|6 years ago|reply
[+] [-] logicallee|6 years ago|reply
That kind of debt, right?
But wait there's more! I forgot to mention that even if you walk away you get to keep what you bought on credit, without any further payment of any kind and it continues working in its current state, forever - you just can't improve or renovate it if you walk away from the debt.¹
That kind of debt, right? If so then perfect analogy.
-
¹ literal lie though, yes you can. you can totally still improve it real quick. I'm afraid I'll have to add $150,000 to your technical debt though, which you can walk away from any time. still want this real quick $50 change though? It might be $50 but it's $150,000 in debt though.
[+] [-] btschaegg|6 years ago|reply
One of which is that it is often really hard to quantify, but that does not seem to stop many non-technical manager types from trying to treat it like financial debt nontheless.
Another one is that unlike financial debt, which should be controlled by various organization-internal mechanisms, tech debt is often not something management is conscious about (at least when it is "created"). I've seen far too many examples of horrible code that can simply be explained with lazyness or incompetence, but I'm pretty sure management never called for a hard to use, unnecessarily complicated API.
Also, if the tech debt is caused by management, it is usually an implicit byproduct of unrealistic time constraints, and I'm pretty sure in those cases they would often choose find another solution too if they were conscious about how bad the problem they're creating really is.
Edit: Either that, or their incentives are way off because they don't have to deal with the consequences. Which is also the real cause why financial debt is usually strictly controlled.
[+] [-] stjohnswarts|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] taeric|6 years ago|reply
Most of what people call debt, though, is really just comprises. Which works, to me, as you can just say the code is too compromised. :)
[+] [-] _asummers|6 years ago|reply
[+] [-] Ericson2314|6 years ago|reply
[+] [-] slumdev|6 years ago|reply
1. You wouldn't pay good money for it if you knew what was under the hood.
2. Most mechanics are reluctant and embarrassed to work on it.
3. Maintenance is going to cost more than you think, probably by a wide margin.
4. You wouldn't expect a major manufacturer to ship a brand new vehicle this way.
5. Nobody who knows what they're doing will ever brag about having a hand in creating it.
[+] [-] lr4444lr|6 years ago|reply
[+] [-] knightofmars|6 years ago|reply
If the individual(s) with power over ones work have spent time writing code then they will most likely have an understanding. If they haven't then it often takes analogies of this nature to help them begin to understand what technical debt is and how it has an impact on the future of the product.
[+] [-] luckydata|6 years ago|reply
One thing I've never seen properly stated is the difference between technical debt as usually described (building code that is doing the job but might not be as flexible, easy to change or fix or might not account for all corner cases appropriately) and then the kind of debt I've experience more often which is "model debt". In the field of business applications, modeling a problem correctly is 80% of the solution, and new companies usually do that job very poorly. Over time as business experience accumulates, some of those mistakes become evident. For example, how to model the identity of the users of an application, that's where the most mindless decisions I've experienced do the most damage. Let's say you assume the only type of user you're gonna have belongs to "companies" and your customers are companies. Then you discover those companies make heavy use of consultants or contractors, and all of a sudden most of your management tools and UI doesn't quite fit. You can hack it, but you end up with a large slice of your users having to manage 20 different emails to interact with your system. Just an example.
"model debt" is the most expensive and potentially fatal type of debt a new piece of software can incur, and my suggestion is for every new project, focus on building a real good model of what reality looks like before too many other technical calls are made, or you're in for a world of hurt.
[+] [-] hammock|6 years ago|reply
[+] [-] rubenbe|6 years ago|reply
The art is to find the sweet spot.
[+] [-] ronnier|6 years ago|reply
> The analogy with technical debt is that each new fix or development is like a new block coming in, which you need to integrate with the existing code. If you hack it in a quick and dirty way, it’s like leaving holes in the Tetris structure: you’re making life more difficult down the line.
[+] [-] jashmenn|6 years ago|reply
[+] [-] thisisastopsign|6 years ago|reply
[+] [-] heisenbit|6 years ago|reply
[+] [-] js8|6 years ago|reply
[+] [-] fizixer|6 years ago|reply
[+] [-] _asummers|6 years ago|reply
[+] [-] mobjack|6 years ago|reply
In reality there is a lot of tech debt you can get away for free and never have to pay back. The code can be a mess but the functionality works and doesn't need updating.
Other tech debt can infect and cripple a system if it isn't contained early.
If you demonstrate that you know how to prioritize the most important tech debt then it is easier to convince management to work on it.
The concept of doing more work now to make future easier is universal. Delivering on it is the hard part.
[+] [-] humanrebar|6 years ago|reply
[+] [-] crimsonalucard|6 years ago|reply
Think about this famous analogy: "Life is like a box of chocolates. You never know what you're gonna get."
I clearly know about how life and a box of chocolates can be random at times. This is dead obvious information to the point of pointlessness. Yet in church or in meetings you see people nod their heads in agreement as if something insightful was said. Here's reality: Nothing insightful was said, the person who was comparing life to a box of chocolates is literally mentally retarded.
Analogies are used to manipulate, not to inform.
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] engManager|6 years ago|reply
[+] [-] zyx321|6 years ago|reply
That's a very low-tier understanding of Tetris. At an intermediate level of play, you'll want to deliberately leave gaps that you could clear at any time, but you choose to wait until it is strategically advantageous to do so.
At an advanced level of play, you'll want to leave oddly-shaped gaps that can only be cleared with a Clever Hack which not everyone is able to understand, let alone perform. (T-Spin)
Similar concepts do exist in programming, they are cynically referred to as "Job Security" but I doubt that the author intended to encourage that sort of behavior.
[+] [-] daenz|6 years ago|reply
I believe that learning how to identify a team that is drowning in tech debt is a valuable interview skill.
[+] [-] Animats|6 years ago|reply
Reading the table of contents of the book, it seems to assume everything is done by hand. There are some power tools for dealing with legacy code in C/C++, but I don't know which ones are any good and for what. A book which covered most of them and wasn't a fan piece for one tool would be helpful.
[1] https://leanpub.com/legacycode
[+] [-] wellpast|6 years ago|reply
It's a lot harder for someone to say "I didn't know how to solve this" and much easier to say "It would take longer to solve it the right way." Because of this you should take claims fo "Technical Debt" with serious suspicion -- and given how fuzzy the general concept is and how enabling it is, I think the proper response is to find it useful far more for personal ego management than as a respectable tool for thinking about execution of software projects.
There is no innate conflict between solid decision-making in a software system and execution time. Generalizations take longer but generalizations or lack thereof do not imply sound architecture; this is orthogonal concerns. But solid execution (decoupled components) is a skillset question. In fact if you have the skillset it often takes longer to make a bad decision.
Technical Debt doesn't respect this (i.e. skills/mastery) and is only good for deflecting from our incompetence and thus keeping us from acquiring the necessary skillset.
[+] [-] jorblumesea|6 years ago|reply
Implementation technical debt (the code) makes it harder for devs to work in a given service, slows down velocity and increases the risk of bugs, but is at least contained to a given service and can be rewritten as a known quantity.
Architectural technical debt will crush your product or your stack, often quickly.
[+] [-] bobbytran|6 years ago|reply
There will almost always be technical debt to some degree when it comes to software. Nothing is perfect and we always dont have the time to create the perfect fix..and instead need to just create something that works.
[+] [-] baud147258|6 years ago|reply
[+] [-] slumos|6 years ago|reply
Sure, that balloon is just sitting there, but every single day you don’t pay it down, you are still paying interest. It slows you down when it causes confusion, when it makes integration more difficult, and when everyone is afraid to make improvements that might require changes to That Godforsaken Class.
And if instead of paying it down, you decide to add more debt, then the interest payments go up / the drag just gets worse.
And let’s be honest, arguing that tech debt is not bad comes up way more often over adding more than deciding not to start paying down.
[+] [-] Twisell|6 years ago|reply