3 ms·

"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 b

"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.

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.