Great talk. I really like your take on the obsolescence of the technical debt concept and the need to move beyond it. Assuming I understood you correctly, I strongly agree with you in that what we call "technical debt" is actually a failure of product management, and that the solution has to include involving engineers much more in product management decisions (which is something Marty Cagan has long been advocating). If you are interested, a few months ago I published an article with input from Michael Feathers that argues along these lines, with a little bit more detail on how to get people to listen.
I usually don't mention fixing tech debt at all. Cleanup is just part of normal workflow, if I touch a certain part of a system I clean up old cruft in that part with it. A restaurant doesn't include "cleanup of the kitchen" as a separate point on the check. If it is a bigger rework and you really need a lot of time just for that, than of course you must convince your customer that the time spent on this is worth it. That means to evaluate and argue with stuff that really matters: money, deadlines or anything that is measurable and the customer cares about. If that doesn't work, either it is not important/worth it for the business or the customer may or may not learns through pain.
I agree with your arguments, but notice that she does make the point that custom development is different from new product development in important ways.
I agree with the notion to categorize and prioritize tech debt as a function of product/business objectives, and that not all tech debt (crust) is worth removing (who does that though). I disagree that we should stop thinking about it. In what is engineering reality trade offs need to be made. Some of these trade offs are good for now but bad for later. That's technical debt. You either fix it or you keep paying interest in the form of more expensive maintenance, future development, support cost or even customer satisfaction.
this is the typical talk of a person disconnected from the reality of software creation costs and the direct implications in business, I mean look at that job title, what it actually means? I've seen businesses with my own eyes dying because of not respecting this debt, you cheap out on development, then hit the wall hard when everything starts to fall at some point.
It's not that teams shouldn't care about tech debt, it's exactly the opposite: let's call it e.g. retrospectives and embrace a culture of continuous improvement, making it part of the everyday work, and remove these tasks from the product backlog as they simply don't belong there, so you won't have priority conflicts between business-level problems to solve and low-level technical details.
She doesn't say we should stop thinking about it, she says we should stop calling it tech debt. The way I understand her point is: instead of making a backlog story saying to address certain tech debt, we should make a story that says we can increase development speed by making this and that change.
Presenter does NOT provide a better, concrete alternative to labelling or quantifying some practices that can lead to low quality final product. Mark Heath has a course on Pluralsight that goes into detail about debt. Technical debt is still a GOOD metaphor that can quantify a software team/company "MATURITY" level. Tech debt is a number of categories 1. Code 2. Architecture 3. Test Suite 4. Overall knowledge about the system (i.e documentation, or what each sub system does) 5. Technology stack Over time atleast one of the categories/items is bound to lag behind and seriously impact overall product output. Presenter's high level solution is to ignore the "problem"
I would find the argument more persuasive if the speaker gave specific examples of what can go wrong when conventional attitudes to technical debt are manifested in a team. What is the problem that will be solved by stopping talking about tech debt?
Unhappy management. She will get a raise and leave after a year to a different company / department, while after one more year the tech debt no one talked about will crush the project.
Well, that's her opening and closing statement actually. It gets hard to prioritize tech debt work, in other words, it gets deprioritized over e.g. working on new features. In my experience this happens at shops that mostly fake agile, like working with low-level tasks or commands on backlogs instead of e.g. stories describing problems to solve. In this case, "tech debt" can be easily interpreted by e.g. management as some work that can be simply neglected. Instead, working on the basis of problems to solve, and treating "tech debt" as e.g. part of the normal work, to achieve technical excellence and maintain a stable pace indefinitely, things can get a lot simpler for the collaboration between the business and development teams (as they will talk on the level of the business problems to solve, not the technical details), and helps development teams to focus on improving the actual bottlenecks as the next stories require it. All these concepts - stable pace of delivery, chasing quality and excellence - are addressed in the manifesto as well for this reason.
Well, she says it quite clearly: Removing the tech debt does not get prioritised. That is the problem that should be solved. She doesn't even say we should stop talking about the technical problems we have with our implementations. She says we should think and talk about them a little differently and to help us do that we should drop the term "tech debt". We should then make it clearer to ourselves and our managers what we gain from changing the implementation. And we should start better prioritising those things ourselves. Because we can't and don't need to change all of it all the time. There is another problem she touched upon: Complaining about how there is all that "tech debt" in our code we even devalue our own work from the past. That is unfair to ourselves and unhealthy. It leads to us being frustrated or even bitter all the time and that in turn can sabotage our relationships to co-workers and managers. It makes it even less likely that we are taken serious because "we always complain about everything, anyway" so why bother? ... I may be speaking from experience here. I better stop.
As she mentioned at the beginning, „Tech Debt“ got introduced to try to explain to non technical people what needs to be done under the surface to keep a product alive. As an engineer I once got told to calculate a business case for things that need to be done under the surface as soon as possible at least from my point of view. Is this what an engineer should do? Calculating business cases for things that can’t be calculated easily upfront, but that are clear for every technically skilled person? Delivering proof for every step that is not clearly a feature? Is this a healthy and trusting culture? At least in my case I tried to explain the why, but if I can’t explain it in terms of money it simply doesn’t count. So debt might not be the best word, but it’s still the best we have.
I want to agree with this, but mostly I cannot. Tech Debt is a fact of life in all serious applications of scale - most, if not all, of it likely a trade-off to get a feature to its intended audience. Yes, tech debt is backward looking, but we take that one step back because it helps us move two steps forward, to make our services generally more resilient, stable, secure, what have you. On some level, everything we write is tech debt in ~5-10 years time, if you're that lucky, and that might generously be assuming that code is near flawless, which we know is not. So rather than stop talking about it (which I think we should not do), how should we make better design decisions, understand and document trade-offs better, make it easier to implement for the "next engineer", etc.
I think its a communication problem. I have no problem getting my tech debt prioritized. But I do call it tech debt. The difference is that I do the work of prioritizing what needs to be done and have arguments for why it needs to be done. I think it's an experience problem and "accept that there will always be debt" is a part of it. Software development skill number one is making smart tradeoffs.
Her point is that "tech debt" should not be mentionned (and seen) as such, but mainly as an issue that will impact the business as a whole, to make it easier for non-tech people to see the interest in it for exemple. It is not something you do to make up for the mistakes of the past, it is something you do so it will be easier going forward.
The funding is the problem. If paying down tech debt is represented as an expense, then we end up with businesses that become more expensive and less predictable to run over time.
Technical debt is not only the source code. It's also updating os, databases, frameworks, programming languages to the latest versions. When you cannot absorb those changes in your project, then you are agile in name only. Also any discussion on cyber security is just a lie then. Compare it to a chef in a 3 star restaurant being forced to cook with ingredients that are expired on best before date and use before date. The customer of that restaurant expects fresh ingredients to be used. The customer of a software package expects up to date components being used. No customer will sign a contract accepting outdated technology, the state of technology is never mentioned in contracts, which doesn't give you the permission to use outdated components
Great point. Non-functional requirements are often an afterthought if not altogether neglected. As Emily correctly identifies, what we call "technical debt" is really a failure of product management. The proof is in the many security breaches that have happened in companies in the security space, such as Verkada and LastPass.
I agree with the speaker's core argument. My key takeaway is that tech debt issues should be re-framed in terms of their "friction cost" i.e. how they hinder change (see ruclips.net/video/KnL_vl2oBag/видео.html). From both practical and political perspectives, the focus is not so much about cleaning away bad code ("clearing the debt") as it is about improving the overall software to be more modifiable.
I do agree that the word "Tech Debt" does get thrown around as a catch all term for something that doesn't related to technology or debt. In my organisation when we mention it, I do think we all agree that it's an actual debt against the product spec, design or implementation that specifically the engineers didn't meet. Eventually for the sake of the business that debt needs to be paid with interest of extra work to resolve. So from this perspective if Emily worked in and with perfect engineering teams who completed their features to the fullest extent and never had to circle back to fix something that is missing (and I'm talking specifically the stuff that really does need to be fixed) then I agree that the use of the word "Tech Debt" doesn't really apply, because at this point you are either dealing with legacy code (old, does not serve a purpose anymore - remove it or replace it) or business needs to rethink what they want to focus on.
I love the presentation and way she gets to the point. Engineers often use the notion of tech debt to rationalize what they think is important. Since it seems like terrible idea not to pay debt so non engineers are tempted to pay it back while losing opportunity to talk about how important or serious that is. So in my opinion, it's just arrogant or lazy not trying to explain why; Every decision should be backed with reasons and those reasons must be understandable in easy words. If it's not, then you're making bad decision and using tech debt as excuse.
Explanation is always understandable and in easy words, "there will be problems later". But... usually some moron called Product Owner says "doesn't matter, produce more features, features, features". That is why Google isn't using Agile, its a dream land for ignorant morons.
So we're now arguing about semantics? Refactoring and continuous improvement should be embedded within the work, not though of something extra that just needs to be done.
Ooh he said the M word. On a serious note, isn't there technical work that improves ease maintenance? For example. upgrading a framework before it goes obsolete is a must, we left it 3 years too late and struggled with tool support and platforms. Not easy to do, cost 10 man-months, can't hide that from management. In the end, even management had to face the cost. It became a series of sprints but there was value to the end user in the form of better UIX.
I think the amount of time and energy that went into this presentation could have been better spent cleaning up the tech debt at her company than looking for new metaphors to describe it.
The analogy presented fell flat for me because she didn't seem to understand that debt, without interest, is literally free money. Why you care about paying back debt is the interest. She didn't bring this up at all and I really got the feeling she didn't even consider that part of the analogy. With technology, interest is paid when working with something and it's more difficult, slow, or worse, than what it could be. This slowness or badness is the cost of otherwise free money.
She understands it quite well, and it is actually a part of her point. If you label something as tech debt, you are likely to want to go back on it without questioning it, because it is a debt. What she is saying is that sometimes, if you cannot justify why you should pay that debt, you should take the free money. If you can justify it, then it is not a "tech" debt, it becomes a problem of the product in itself and should be labeled as such. It becomes a "timely, product-strategy-relevant improvement recommendation" as she calls it
Yeah! Absolutely agree, lets talk less about tech debt and throw more money on QA engineers, test environments, do more regression tests because every change can break some functionality on the other end. Let's hire more devs to work with messy projects, lets spend more money on hiring new devs because old ones are burnt out and the new ones burning out before they even figure out how the project is structured. Stop talking about tech debt! We need to deliver ASAP, ASAP, ASAP! Money is dust. And don't even try to allocate time on system design, leave it for interviews, it's better to hire a dev who can explain how to design Amazon in 30 minutes. Agile!
How do you manage to watch a 20 minutes video and completely miss the point ? Her whole point is that a "tech" debt that starts (or could start) to have real implication should not be labeled as "tech" debt, and should be considered as a problem with the product as a whole. That way, it becomes clearer for everyone that this thing should be done, because it is not only something that the nerds want to make their life better, but it is a product issue that will impact futur releases. For exemple: "Because we were focused on releasing fast at the start of the project, we have been neglecting our tests and the risk of regression start to become really high, which would anger our customers. Taking time to improve our tests will greatly reduce that risk and keep the customers happy as our software becomes more reliable" is better than "Because we were focused on releasing fast at the start of the project, we have been neglecting our tests, so we have accumulated some tech debt that we should pay back now" The problem you are describing in your comment is not a "tech" problem. Spending more money on QA engineers, tests evts and regression tests is a company issue and should be labeled as such.
"What should we do instead?" Well...ignore the problem (technical debt) long enough...pretend it is not there...sugar coat the problem...dance around it...call it something else ...then one day it will MAGICALLY DISSAPEAR.
Tech debt is just an outdated system’s model in front of a new meaning of the system from technical or business standpoint accessible to the system’s solution builders.
same as president Biden, if he can’t increase GPD, redefine the GDP, then make it increase 😂 that makes Biden as president. If she can’t pay the technical debt, redefine what debt is😂 and that makes her as senior director
![[#2024MAMA] G-DRAGON - 무제(Untitled, 2014)+POWER+HOME SWEET HOME+뱅뱅뱅+FANTASTIC BABY | Mnet 241123 방송](http://i.ytimg.com/vi/Ox29z5Nf1Uk/mqdefault.jpg)
Great talk. I really like your take on the obsolescence of the technical debt concept and the need to move beyond it. Assuming I understood you correctly, I strongly agree with you in that what we call "technical debt" is actually a failure of product management, and that the solution has to include involving engineers much more in product management decisions (which is something Marty Cagan has long been advocating). If you are interested, a few months ago I published an article with input from Michael Feathers that argues along these lines, with a little bit more detail on how to get people to listen.
I usually don't mention fixing tech debt at all. Cleanup is just part of normal workflow, if I touch a certain part of a system I clean up old cruft in that part with it. A restaurant doesn't include "cleanup of the kitchen" as a separate point on the check. If it is a bigger rework and you really need a lot of time just for that, than of course you must convince your customer that the time spent on this is worth it. That means to evaluate and argue with stuff that really matters: money, deadlines or anything that is measurable and the customer cares about. If that doesn't work, either it is not important/worth it for the business or the customer may or may not learns through pain.
I agree with your arguments, but notice that she does make the point that custom development is different from new product development in important ways.
I agree with the notion to categorize and prioritize tech debt as a function of product/business objectives, and that not all tech debt (crust) is worth removing (who does that though). I disagree that we should stop thinking about it. In what is engineering reality trade offs need to be made. Some of these trade offs are good for now but bad for later. That's technical debt. You either fix it or you keep paying interest in the form of more expensive maintenance, future development, support cost or even customer satisfaction.
this is the typical talk of a person disconnected from the reality of software creation costs and the direct implications in business, I mean look at that job title, what it actually means?
I've seen businesses with my own eyes dying because of not respecting this debt, you cheap out on development, then hit the wall hard when everything starts to fall at some point.
It's not that teams shouldn't care about tech debt, it's exactly the opposite: let's call it e.g. retrospectives and embrace a culture of continuous improvement, making it part of the everyday work, and remove these tasks from the product backlog as they simply don't belong there, so you won't have priority conflicts between business-level problems to solve and low-level technical details.
She doesn't say we should stop thinking about it, she says we should stop calling it tech debt. The way I understand her point is: instead of making a backlog story saying to address certain tech debt, we should make a story that says we can increase development speed by making this and that change.
Presenter does NOT provide a better, concrete alternative to labelling or quantifying some practices that can lead to low quality final product.
Mark Heath has a course on Pluralsight that goes into detail about debt. Technical debt is still a GOOD metaphor that can quantify a software team/company "MATURITY" level.
Tech debt is a number of categories
1. Code
2. Architecture
3. Test Suite
4. Overall knowledge about the system (i.e documentation, or what each sub system does)
5. Technology stack
Over time atleast one of the categories/items is bound to lag behind and seriously impact overall product output. Presenter's high level solution is to ignore the "problem"
I would find the argument more persuasive if the speaker gave specific examples of what can go wrong when conventional attitudes to technical debt are manifested in a team. What is the problem that will be solved by stopping talking about tech debt?
Easy, she invests less money in her engineers.
Unhappy management. She will get a raise and leave after a year to a different company / department, while after one more year the tech debt no one talked about will crush the project.
Well, that's her opening and closing statement actually. It gets hard to prioritize tech debt work, in other words, it gets deprioritized over e.g. working on new features.
In my experience this happens at shops that mostly fake agile, like working with low-level tasks or commands on backlogs instead of e.g. stories describing problems to solve. In this case, "tech debt" can be easily interpreted by e.g. management as some work that can be simply neglected.
Instead, working on the basis of problems to solve, and treating "tech debt" as e.g. part of the normal work, to achieve technical excellence and maintain a stable pace indefinitely, things can get a lot simpler for the collaboration between the business and development teams (as they will talk on the level of the business problems to solve, not the technical details), and helps development teams to focus on improving the actual bottlenecks as the next stories require it.
All these concepts - stable pace of delivery, chasing quality and excellence - are addressed in the manifesto as well for this reason.
Well, she says it quite clearly: Removing the tech debt does not get prioritised. That is the problem that should be solved. She doesn't even say we should stop talking about the technical problems we have with our implementations. She says we should think and talk about them a little differently and to help us do that we should drop the term "tech debt". We should then make it clearer to ourselves and our managers what we gain from changing the implementation. And we should start better prioritising those things ourselves. Because we can't and don't need to change all of it all the time.
There is another problem she touched upon: Complaining about how there is all that "tech debt" in our code we even devalue our own work from the past. That is unfair to ourselves and unhealthy. It leads to us being frustrated or even bitter all the time and that in turn can sabotage our relationships to co-workers and managers. It makes it even less likely that we are taken serious because "we always complain about everything, anyway" so why bother? ... I may be speaking from experience here. I better stop.
As she mentioned at the beginning, „Tech Debt“ got introduced to try to explain to non technical people what needs to be done under the surface to keep a product alive.
As an engineer I once got told to calculate a business case for things that need to be done under the surface as soon as possible at least from my point of view. Is this what an engineer should do? Calculating business cases for things that can’t be calculated easily upfront, but that are clear for every technically skilled person? Delivering proof for every step that is not clearly a feature? Is this a healthy and trusting culture? At least in my case I tried to explain the why, but if I can’t explain it in terms of money it simply doesn’t count. So debt might not be the best word, but it’s still the best we have.
I want to agree with this, but mostly I cannot. Tech Debt is a fact of life in all serious applications of scale - most, if not all, of it likely a trade-off to get a feature to its intended audience. Yes, tech debt is backward looking, but we take that one step back because it helps us move two steps forward, to make our services generally more resilient, stable, secure, what have you.
On some level, everything we write is tech debt in ~5-10 years time, if you're that lucky, and that might generously be assuming that code is near flawless, which we know is not. So rather than stop talking about it (which I think we should not do), how should we make better design decisions, understand and document trade-offs better, make it easier to implement for the "next engineer", etc.
I think its a communication problem. I have no problem getting my tech debt prioritized. But I do call it tech debt. The difference is that I do the work of prioritizing what needs to be done and have arguments for why it needs to be done. I think it's an experience problem and "accept that there will always be debt" is a part of it. Software development skill number one is making smart tradeoffs.
Her point is that "tech debt" should not be mentionned (and seen) as such, but mainly as an issue that will impact the business as a whole, to make it easier for non-tech people to see the interest in it for exemple.
It is not something you do to make up for the mistakes of the past, it is something you do so it will be easier going forward.
The funding is the problem. If paying down tech debt is represented as an expense, then we end up with businesses that become more expensive and less predictable to run over time.
Technical debt is not only the source code. It's also updating os, databases, frameworks, programming languages to the latest versions. When you cannot absorb those changes in your project, then you are agile in name only. Also any discussion on cyber security is just a lie then. Compare it to a chef in a 3 star restaurant being forced to cook with ingredients that are expired on best before date and use before date.
The customer of that restaurant expects fresh ingredients to be used. The customer of a software package expects up to date components being used.
No customer will sign a contract accepting outdated technology, the state of technology is never mentioned in contracts, which doesn't give you the permission to use outdated components
Great point. Non-functional requirements are often an afterthought if not altogether neglected. As Emily correctly identifies, what we call "technical debt" is really a failure of product management. The proof is in the many security breaches that have happened in companies in the security space, such as Verkada and LastPass.
I agree with the speaker's core argument. My key takeaway is that tech debt issues should be re-framed in terms of their "friction cost" i.e. how they hinder change (see ruclips.net/video/KnL_vl2oBag/видео.html).
From both practical and political perspectives, the focus is not so much about cleaning away bad code ("clearing the debt") as it is about improving the overall software to be more modifiable.
Summary: "I can't get my tech debt prioritized" --> "I can get my timely, product-strategy-relevant improvement recommendations prioritized"
I do agree that the word "Tech Debt" does get thrown around as a catch all term for something that doesn't related to technology or debt. In my organisation when we mention it, I do think we all agree that it's an actual debt against the product spec, design or implementation that specifically the engineers didn't meet. Eventually for the sake of the business that debt needs to be paid with interest of extra work to resolve.
So from this perspective if Emily worked in and with perfect engineering teams who completed their features to the fullest extent and never had to circle back to fix something that is missing (and I'm talking specifically the stuff that really does need to be fixed) then I agree that the use of the word "Tech Debt" doesn't really apply, because at this point you are either dealing with legacy code (old, does not serve a purpose anymore - remove it or replace it) or business needs to rethink what they want to focus on.
I love the presentation and way she gets to the point.
Engineers often use the notion of tech debt to rationalize what they think is important. Since it seems like terrible idea not to pay debt so non engineers are tempted to pay it back while losing opportunity to talk about how important or serious that is.
So in my opinion, it's just arrogant or lazy not trying to explain why; Every decision should be backed with reasons and those reasons must be understandable in easy words. If it's not, then you're making bad decision and using tech debt as excuse.
Explanation is always understandable and in easy words, "there will be problems later". But... usually some moron called Product Owner says "doesn't matter, produce more features, features, features". That is why Google isn't using Agile, its a dream land for ignorant morons.
So we're now arguing about semantics? Refactoring and continuous improvement should be embedded within the work, not though of something extra that just needs to be done.
Ooh he said the M word.
On a serious note, isn't there technical work that improves ease maintenance? For example. upgrading a framework before it goes obsolete is a must, we left it 3 years too late and struggled with tool support and platforms. Not easy to do, cost 10 man-months, can't hide that from management. In the end, even management had to face the cost. It became a series of sprints but there was value to the end user in the form of better UIX.
So does it happen that often that people complain about tech debt not being prioritized when said debt is irrelevant?
I think the amount of time and energy that went into this presentation could have been better spent cleaning up the tech debt at her company than looking for new metaphors to describe it.
😂
Eventually you just pile up "tech debt" until it becomes a blocker for the next hot feature that everyone in proudct management wants to edge to.
The analogy presented fell flat for me because she didn't seem to understand that debt, without interest, is literally free money. Why you care about paying back debt is the interest. She didn't bring this up at all and I really got the feeling she didn't even consider that part of the analogy.
With technology, interest is paid when working with something and it's more difficult, slow, or worse, than what it could be. This slowness or badness is the cost of otherwise free money.
She understands it quite well, and it is actually a part of her point. If you label something as tech debt, you are likely to want to go back on it without questioning it, because it is a debt. What she is saying is that sometimes, if you cannot justify why you should pay that debt, you should take the free money.
If you can justify it, then it is not a "tech" debt, it becomes a problem of the product in itself and should be labeled as such. It becomes a "timely, product-strategy-relevant improvement recommendation" as she calls it
Yeah! Absolutely agree, lets talk less about tech debt and throw more money on QA engineers, test environments, do more regression tests because every change can break some functionality on the other end. Let's hire more devs to work with messy projects, lets spend more money on hiring new devs because old ones are burnt out and the new ones burning out before they even figure out how the project is structured.
Stop talking about tech debt! We need to deliver ASAP, ASAP, ASAP! Money is dust.
And don't even try to allocate time on system design, leave it for interviews, it's better to hire a dev who can explain how to design Amazon in 30 minutes.
Agile!
How do you manage to watch a 20 minutes video and completely miss the point ?
Her whole point is that a "tech" debt that starts (or could start) to have real implication should not be labeled as "tech" debt, and should be considered as a problem with the product as a whole. That way, it becomes clearer for everyone that this thing should be done, because it is not only something that the nerds want to make their life better, but it is a product issue that will impact futur releases.
For exemple: "Because we were focused on releasing fast at the start of the project, we have been neglecting our tests and the risk of regression start to become really high, which would anger our customers. Taking time to improve our tests will greatly reduce that risk and keep the customers happy as our software becomes more reliable" is better than "Because we were focused on releasing fast at the start of the project, we have been neglecting our tests, so we have accumulated some tech debt that we should pay back now"
The problem you are describing in your comment is not a "tech" problem. Spending more money on QA engineers, tests evts and regression tests is a company issue and should be labeled as such.
"What should we do instead?"
Well...ignore the problem (technical debt) long enough...pretend it is not there...sugar coat the problem...dance around it...call it something else
...then one day it will MAGICALLY DISSAPEAR.
I would like to see the code and solutions of department she is responsible for.
Tech debt is just an outdated system’s model in front of a new meaning of the system from technical or business standpoint accessible to the system’s solution builders.
Not a good talk. Speaker does not seam to really understand what tech debt is.
14:18 if Steve Jobs is still alive, he would say it matters 😊
same as president Biden, if he can’t increase GPD, redefine the GDP, then make it increase 😂 that makes Biden as president.
If she can’t pay the technical debt, redefine what debt is😂 and that makes her as senior director
Sigma male Biden