6 ms·

> If the technical debt is a problem, 1) we shouldn’t have put it in there, and 2) we should include it in our estimates and address it. Yes. Don't tell your b

> If the technical debt is a problem, 1) we shouldn’t have put it in there, and 2) we should include it in our estimates and address it. Yes. Don't tell your boss that you'll need to take time to address technical debt. The boss will always say "No don't do that, just add the feature". Sometimes they add "We'll fix that later." Later never happens and eliminating related technical debt is part of implementing the feature. Don't ask your boss about this stuff. It's part of your job and it's something you understand that your boss probably doesn't.

thayne 2y ago
That's all well and good until you have to explain that the reason building something they think should take a week will take 6 months because you have to fix tech debt, or avoid adding new tech debt.
- justin_oaks 2y ago
  A professional balances the need for quality with the urgency of the task. Your example shows a clear imbalance that indicates the person is not a professional; that person is someone who can't be trusted with that balance.
  - thayne 2y ago
    Sure, you need to balance urgency and quality, but that doesn't mean you shouldn't ever communicate about that tradeoff to stakeholders. Let me give a somewhat concrete example. Someone from business came to me to ask how hard it would be to fix a bug. It wasn't super urgent. The user experience of the bug wasn't too bad, a minor annoyance. But it seemed like such a small thing that they thought the fix couldn't take more than a few days. When I informed them it would take weeks at a minimum and more likely months, they were very confused, until I explained that a design made in the early days of the company (before I worked there) made this particular bug extremely difficult to fix. We would either have to redesign an entire system in a more robust way, or work around the limitations of the current system which would be faster, but still much more difficult than ot should be. And doing so wouldn't help at all with fixing the myriad other problems caused by this design choice. And although I wasn't involved in the original design, I think at the time it wasn't a terrible decision. It allowed the company to get something out that worked pretty well, and helped the company grow quickly. But now that technical debt was slowing down other development.
noisy_boy 2y ago
> Sometimes they add "We'll fix that later." The answer to that answer is more questions: - how will we fix it, properly, later when we can't fix it now? Won't there be more features to be done later? - what if we fix it later and it creates its own issues and then someone will ask why did we touch it when it was working? If it breaks now, we can fix those breakages because we are already touching it. - if later, as part of which release? Don't actually ask these questions - they will piss-off your boss even more.
RangerScience 2y ago
You know I wonder… why do so many of us feel like we need our boss to understand?
- vundercind 2y ago
  Because their opinion of us may contribute to how comfortable we are at work, how well we’re compensated, and whether we get promoted. If they don’t understand what we’re doing or why things take as long as they do, that’s bad for us.
- hobs 2y ago
  Because the boss says they want to understand, drags you to endless meetings to understand, but then manages to makes arbitrary decisions based on none of that information.
- rapfaria 2y ago
  Perhaps it's not a close relationship. Perhaps the boss is insecure about his management skills and has to constantly check on the team, to make sure every variable is under his radar.
- onion2k 2y ago
  Most of us work in organizations where the boss is a former engineer who understands the problem of tech debt perfectly well. If your boss is a former dev and they aren't taking it seriously the problem is usually that they're a bit too keen to say yes to other parts of the business.
YZF 2y ago
This is not the right answer for a real business. Sometimes we'll fix that later is perfectly acceptable. If that was good enough for Facebook it can certainly be good enough for others.
- justin_oaks 2y ago
  "We'll fix that later" is at best a hopeful fantasy, and at worst a lie intended to manipulate. It doesn't happen. We need to be clear here. If what needs to be fixed is something that will inevitably cause serious problems down the road, then it should be fixed immediately. If it may cause minor problems then maybe you should never fix it. And there's a lot in between. The biggest problem is that bosses aren't in a good position to understand the code you're looking at. So if you're a professional, you'll make the call as to whether or not some tech debt is worth fixing now or not. The boss's job is to communicate the urgency and importance of your task, how it fits in with the company's goals, etc. Your job is to carry out the task with a reasonably balanced ratio of quality to time.
  - vineyardmike 2y ago
    > We need to be clear here. If what needs to be fixed is something that will inevitably cause serious problems down the road, then it should be fixed immediately. If it may cause minor problems then maybe you should never fix it. And there's a lot in between. I feel like a lot of conversations around technical debt miss this nuance. There are plenty of systems I’ve worked on that have been either (1) running for years without issue or (2) deprecated and deleted without ever addressing most of the “debt” issues/tickets that my team and I created in our tracking systems. I think a lot of engineers take pride in their craft (which is good). Until you learn that a cabinet with a rough back is still a great cabinet, you’re doomed to feel uneasy about leaving something “unfinished”. So many people feel they left some “hack” in the code they want to fix. Which is different than a bug. There are endless improvements possible. YAGNI.
  - YZF 2y ago
    I'm sorry but no. Something that will inevitably cause serious trouble down the road doesn't have to be fixed immediately. It can be fixed later. The proper decision for the business is whether the "interest" on waiting is worth it. There are many examples of this in the real world. It's simply not true that "fix later" is always a lie. What's more likely to be the case is that as new requirements are discovered there will be churn and it'll turn out it wasn't actually worth fixing this thing that you thought would cause serious trouble "down the road". I'm a "boss" and I'm a software engineer. My bosses are also software people. My CEO is a software engineer. What I expect my team to do is to give me the tradeoffs. What I don't want them to do is make business calls. If we lose a huge business opportunity because we can't make a milestone with a customer because an engineer made a decision on his own to spend weeks dealing with some corner case and the whole company goes down the drain that engineer is not professional. Again we're not talking about situations where this would be unethical, we're talking about a tradeoff a business makes to go forward with certain limitations of some software in order to meet some business goal.
strken 2y ago
The name "tech debt" has always been a bit of a misnomer. Financial debt does come with interest, but it's structured, proportionate, and you can just go pay it off with sufficient money. Tech debt is unpredictable, needs a lot of context to comprehend, needs even more to fix, is subject to the mythical man month, and taints everything else it touches in your product. It can be worth accepting such a structural flaw into your product, for a time, but it's certainly not like asking for an extension of credit. It's a struggle to come up with a better name, though.
- delusional 2y ago
  It's an incredible share that we've accepted the "technical debt" metaphor so deeply into our vocabulary that we can't discuss the practical problem without devolving into interpreting the metaphor. The practical definition is clear. It's a lack of maintenence of core abstraction. Leftovers from different designs, deeply embedded into our solution. Sometimes we plan for it to live in a corner somewhere, but more often we discover the failure of some abstraction all too late. It doesn't work like debt at all. We didn't sign a termsheet, and we didn't calculate the impact. We need to move beyond this hopeless metaphor such that we can actually discuss what software needs, because right we're staring at a field emptied of nitrogen by years of farming and saying it has a "resource debt"
  - lloeki 2y ago
    > We didn't sign a termsheet, and we didn't calculate the impact. Which is very much like going to the bank and trusting it that it's going to be ok without looking at numbers; or going to a mob shark for a loan, but it's actually Darth Vader and he'll make sure to alter the deal any way he sees fit. Evaluating what tech debt is going to cost (through coupling and accidental complexity) is definitely part of the job. That responsible engineers yelling it's going to cost a lot are then ignored is part of the systemic cultural problem.
- singleshot_ 2y ago
  I don’t think I’d agree that financial debt is by definition structured given the concept known as “unstructured debt.”

thayne 2y ago

That's all well and good until you have to explain that the reason building something they think should take a week will take 6 months because you have to fix tech debt, or avoid adding new tech debt.

justin_oaks 2y ago
A professional balances the need for quality with the urgency of the task. Your example shows a clear imbalance that indicates the person is not a professional; that person is someone who can't be trusted with that balance.
- thayne 2y ago
  Sure, you need to balance urgency and quality, but that doesn't mean you shouldn't ever communicate about that tradeoff to stakeholders. Let me give a somewhat concrete example. Someone from business came to me to ask how hard it would be to fix a bug. It wasn't super urgent. The user experience of the bug wasn't too bad, a minor annoyance. But it seemed like such a small thing that they thought the fix couldn't take more than a few days. When I informed them it would take weeks at a minimum and more likely months, they were very confused, until I explained that a design made in the early days of the company (before I worked there) made this particular bug extremely difficult to fix. We would either have to redesign an entire system in a more robust way, or work around the limitations of the current system which would be faster, but still much more difficult than ot should be. And doing so wouldn't help at all with fixing the myriad other problems caused by this design choice. And although I wasn't involved in the original design, I think at the time it wasn't a terrible decision. It allowed the company to get something out that worked pretty well, and helped the company grow quickly. But now that technical debt was slowing down other development.

noisy_boy 2y ago

> Sometimes they add "We'll fix that later." The answer to that answer is more questions: - how will we fix it, properly, later when we can't fix it now? Won't there be more features to be done later? - what if we fix it later and it creates its own issues and then someone will ask why did we touch it when it was working? If it breaks now, we can fix those breakages because we are already touching it. - if later, as part of which release? Don't actually ask these questions - they will piss-off your boss even more.

RangerScience 2y ago

You know I wonder… why do so many of us feel like we need our boss to understand?

vundercind 2y ago
Because their opinion of us may contribute to how comfortable we are at work, how well we’re compensated, and whether we get promoted. If they don’t understand what we’re doing or why things take as long as they do, that’s bad for us.
hobs 2y ago
Because the boss says they want to understand, drags you to endless meetings to understand, but then manages to makes arbitrary decisions based on none of that information.
rapfaria 2y ago
Perhaps it's not a close relationship. Perhaps the boss is insecure about his management skills and has to constantly check on the team, to make sure every variable is under his radar.
onion2k 2y ago
Most of us work in organizations where the boss is a former engineer who understands the problem of tech debt perfectly well. If your boss is a former dev and they aren't taking it seriously the problem is usually that they're a bit too keen to say yes to other parts of the business.

YZF 2y ago

This is not the right answer for a real business. Sometimes we'll fix that later is perfectly acceptable. If that was good enough for Facebook it can certainly be good enough for others.

justin_oaks 2y ago
"We'll fix that later" is at best a hopeful fantasy, and at worst a lie intended to manipulate. It doesn't happen. We need to be clear here. If what needs to be fixed is something that will inevitably cause serious problems down the road, then it should be fixed immediately. If it may cause minor problems then maybe you should never fix it. And there's a lot in between. The biggest problem is that bosses aren't in a good position to understand the code you're looking at. So if you're a professional, you'll make the call as to whether or not some tech debt is worth fixing now or not. The boss's job is to communicate the urgency and importance of your task, how it fits in with the company's goals, etc. Your job is to carry out the task with a reasonably balanced ratio of quality to time.
- vineyardmike 2y ago
  > We need to be clear here. If what needs to be fixed is something that will inevitably cause serious problems down the road, then it should be fixed immediately. If it may cause minor problems then maybe you should never fix it. And there's a lot in between. I feel like a lot of conversations around technical debt miss this nuance. There are plenty of systems I’ve worked on that have been either (1) running for years without issue or (2) deprecated and deleted without ever addressing most of the “debt” issues/tickets that my team and I created in our tracking systems. I think a lot of engineers take pride in their craft (which is good). Until you learn that a cabinet with a rough back is still a great cabinet, you’re doomed to feel uneasy about leaving something “unfinished”. So many people feel they left some “hack” in the code they want to fix. Which is different than a bug. There are endless improvements possible. YAGNI.
- YZF 2y ago
  I'm sorry but no. Something that will inevitably cause serious trouble down the road doesn't have to be fixed immediately. It can be fixed later. The proper decision for the business is whether the "interest" on waiting is worth it. There are many examples of this in the real world. It's simply not true that "fix later" is always a lie. What's more likely to be the case is that as new requirements are discovered there will be churn and it'll turn out it wasn't actually worth fixing this thing that you thought would cause serious trouble "down the road". I'm a "boss" and I'm a software engineer. My bosses are also software people. My CEO is a software engineer. What I expect my team to do is to give me the tradeoffs. What I don't want them to do is make business calls. If we lose a huge business opportunity because we can't make a milestone with a customer because an engineer made a decision on his own to spend weeks dealing with some corner case and the whole company goes down the drain that engineer is not professional. Again we're not talking about situations where this would be unethical, we're talking about a tradeoff a business makes to go forward with certain limitations of some software in order to meet some business goal.

strken 2y ago

The name "tech debt" has always been a bit of a misnomer. Financial debt does come with interest, but it's structured, proportionate, and you can just go pay it off with sufficient money. Tech debt is unpredictable, needs a lot of context to comprehend, needs even more to fix, is subject to the mythical man month, and taints everything else it touches in your product. It can be worth accepting such a structural flaw into your product, for a time, but it's certainly not like asking for an extension of credit. It's a struggle to come up with a better name, though.

delusional 2y ago
It's an incredible share that we've accepted the "technical debt" metaphor so deeply into our vocabulary that we can't discuss the practical problem without devolving into interpreting the metaphor. The practical definition is clear. It's a lack of maintenence of core abstraction. Leftovers from different designs, deeply embedded into our solution. Sometimes we plan for it to live in a corner somewhere, but more often we discover the failure of some abstraction all too late. It doesn't work like debt at all. We didn't sign a termsheet, and we didn't calculate the impact. We need to move beyond this hopeless metaphor such that we can actually discuss what software needs, because right we're staring at a field emptied of nitrogen by years of farming and saying it has a "resource debt"
- lloeki 2y ago
  > We didn't sign a termsheet, and we didn't calculate the impact. Which is very much like going to the bank and trusting it that it's going to be ok without looking at numbers; or going to a mob shark for a loan, but it's actually Darth Vader and he'll make sure to alter the deal any way he sees fit. Evaluating what tech debt is going to cost (through coupling and accidental complexity) is definitely part of the job. That responsible engineers yelling it's going to cost a lot are then ignored is part of the systemic cultural problem.
singleshot_ 2y ago
I don’t think I’d agree that financial debt is by definition structured given the concept known as “unstructured debt.”