We sound like idiots when we talk about technical debt
1–10 of 198 posts
Re: We sound like idiots when we talk about technical debt
#2Usually, the discussion goes the other way around.
Product is pissed because delivery is stagnated and that's because of technical debt.
Product: We need that change for Big Co.
Techie: Okay, that takes two weeks.
Product: Two weeks? For such a small change??
Techie: Yes, because we are drowing in technical debt and you're priorizing features and not maintanence.
Also, usually techies don't care.
Why? Because it's always good to have an excuse to work slower.
Re: We sound like idiots when we talk about technical debt
#3Technical debt and its costs are extremely hard to quantify and saying things like "with 3-6 weeks of engineering time we can cut failures in half" is just inventing numbers to get what you want.
Re: We sound like idiots when we talk about technical debt
#4Usually, the discussion goes the other way around. Product is pissed because delivery is stagnated and that's because of technical debt. Product: We need that change for Big Co. Techie: Okay, that takes two weeks. Product: Two weeks? For such a small change?? Techie: Yes, because we are drowing in technical debt and you're priorizing features and not maintanence. Also, usually techies don't care. Why? Because it's al…
Features have a lot of development advantages over maintenance. Features are fun and rewarding to implement. Maintenance is boring. This seems small, but it's actually huge. Feature work can be done many times faster because of it. I got hired at my current job because people left because the feature phase was over and they didn't want to do maintenance. I'm probably going to leave because this work is simply not interesting.
Re: We sound like idiots when we talk about technical debt
#5Usually, the discussion goes the other way around. Product is pissed because delivery is stagnated and that's because of technical debt. Product: We need that change for Big Co. Techie: Okay, that takes two weeks. Product: Two weeks? For such a small change?? Techie: Yes, because we are drowing in technical debt and you're priorizing features and not maintanence. Also, usually techies don't care. Why? Because it's al…
Yeah, I didn't find the intro conversation in the article familiar at all. And also, if a one day change is taking a week then when asked "Oh really! What is it costing us?" the answer is 5x what it should. It's incredibly easy to directly link technical debt to running costs.
Re: We sound like idiots when we talk about technical debt
#6Usually, the discussion goes the other way around. Product is pissed because delivery is stagnated and that's because of technical debt. Product: We need that change for Big Co. Techie: Okay, that takes two weeks. Product: Two weeks? For such a small change?? Techie: Yes, because we are drowing in technical debt and you're priorizing features and not maintanence. Also, usually techies don't care. Why? Because it's al…
Features have a lot of development advantages over maintenance. Features are fun and rewarding to implement. Maintenance is boring. This seems small, but it's actually huge. Feature work can be done many times faster because of it. I got hired at my current job because people left because the feature phase was over and they didn't want to do maintenance. I'm probably going to leave because this work is simply not int…
I _love_ maintenance and fixing technical debt, much more than working on features.
Re: We sound like idiots when we talk about technical debt
#7Technical debt and its costs are extremely hard to quantify and saying things like "with 3-6 weeks of engineering time we can cut failures in half" is just inventing numbers to get what you want.
This. I came here to express exactly the same feeling, but I think you wrote it better than me !
Re: We sound like idiots when we talk about technical debt
#8Usually it's hard to quantify technical debt. And anyway, when debt is first accumulated, it has no downsides. When you first take out a loan, you don't pay anything for the first month. Without understanding the long term nature of debt and interest, you will see it as free money.
Business leaders have wisely learned how finances work, and financial debt. We need to learn how software engineering works, and technical debt. It's relatively new. Business has a long history, going back to the days of kings. Imagine a conversation with a king who hadn't learned about financial instruments.
King: We need to raise an army.
Duke: Okay, but we're out of money. We'd have to borrow more.
King: Are we able to borrow money for it?
Duke: Yes, but our debts are racking up, and there could be future consequences.
King: Sounds like we can borrow money, do it.
Re: We sound like idiots when we talk about technical debt
#9Usually, the discussion goes the other way around. Product is pissed because delivery is stagnated and that's because of technical debt. Product: We need that change for Big Co. Techie: Okay, that takes two weeks. Product: Two weeks? For such a small change?? Techie: Yes, because we are drowing in technical debt and you're priorizing features and not maintanence. Also, usually techies don't care. Why? Because it's al…
Features have a lot of development advantages over maintenance. Features are fun and rewarding to implement. Maintenance is boring. This seems small, but it's actually huge. Feature work can be done many times faster because of it. I got hired at my current job because people left because the feature phase was over and they didn't want to do maintenance. I'm probably going to leave because this work is simply not int…
I don't think I've ever worked in an environment where the tech team would have resisted the opportunity to take some time to refactor or update some systems that needed attention. In fact, they'd most likely be overjoyed and would much rather do this than implement features. YMMV from team to team, though.
Re: We sound like idiots when we talk about technical debt
#10Not all technical debt is the same. Some things may be more aesthetic in nature. Other things more serious. Even for these more substantive problems, technical debt can usually be ignored, for a while at least. Then when it can’t, major problems can arise. This strikes me as similar to insecure code. It’s not a problem until it is a problem, then it’s a big deal. But it can be difficult to quantify the costs-benefits of dealing with technical debt before it is too late.