5 ms·

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

by 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.
speed_spread 2y ago
Its up to the engineers to factor in maintenance work as part of their estimates. Business people assume perfect software and react badly when confronted with the messiness of software development. Also, Facebook being a real business is questionable.
- YZF 2y ago
  Meta's market cap is 1.2T, it has $60B cash, revenue 143B a quarter... Not a real business? I mean maybe the original team in FB should have made sure they didn't accumulate technical debt and FB having failed would be a better outcome for shareholders. Engineers need to give the business the options. Not unilaterally decide that they're not going to accumulate technical debt. That's my point. And trust me, business people don't assume perfect software (at least if they've been in business for any amount of time). [EDIT: What's maybe different about] business people is they a) look at things as a negotiation. b) want to get the max value for their investment c) likely have seen a lot of engineering projects from the outside. Engineering needs to work with the business not go and decide what's right for the business. This doesn't mean you don't have ethical responsibilities as a software engineer in many situations but there are also many situations where the business needs to call the right balance between engineering effort the things like quality or feature sets.
  - Aeolun 2y ago
    I don’t think biz is in any position to decide that. They can tell us when something needs to be delivered by, and we can decide which corners need to be cut to achieve that.
  - bee_rider 2y ago
    The IEEE code of ethics https://www.ieee.org/about/corporate/governance/p7-8.html https://www.ieee.org/about/corporate/governance/p7-8.html Would seem to preclude working on a site, like Facebook > 1. to hold paramount the safety, health, and welfare of the public, to strive to comply with ethical design and sustainable development practices, to protect the privacy of others, and to disclose promptly factors that might endanger the public or the environment; Given that sites like Facebook have been used to spread medical conspiracy theories (health of the public), the whole business model is privacy violations, and the site was used to enable the Rohingya massacre (safety/welfare of the public), https://www.pbs.org/newshour/amp/world/amnesty-report-finds-facebook-amplified-hate-ahead-of-rohingya-massacre-in-myanmar https://www.pbs.org/newshour/amp/world/amnesty-report-finds-... But I mean an ethical engineer wouldn’t get in the way of a place like Facebook because they wouldn’t work there in the first place.
mook 2y ago
And sometimes — quite a lot of the time, in fact — never fixing it is the way to go. It sucks, your users will keep complaining about it, and it'll nag you at the back of your mind forever. But if fixing things properly means somebody else ships first and you have no users and you get cancelled, that bug still wouldn't have been fixed. But sometimes your product is so buggy nobody wants to use it. It's all trade-offs, just like… well, engineering.

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

speed_spread 2y ago

Its up to the engineers to factor in maintenance work as part of their estimates. Business people assume perfect software and react badly when confronted with the messiness of software development. Also, Facebook being a real business is questionable.

YZF 2y ago
Meta's market cap is 1.2T, it has $60B cash, revenue 143B a quarter... Not a real business? I mean maybe the original team in FB should have made sure they didn't accumulate technical debt and FB having failed would be a better outcome for shareholders. Engineers need to give the business the options. Not unilaterally decide that they're not going to accumulate technical debt. That's my point. And trust me, business people don't assume perfect software (at least if they've been in business for any amount of time). [EDIT: What's maybe different about] business people is they a) look at things as a negotiation. b) want to get the max value for their investment c) likely have seen a lot of engineering projects from the outside. Engineering needs to work with the business not go and decide what's right for the business. This doesn't mean you don't have ethical responsibilities as a software engineer in many situations but there are also many situations where the business needs to call the right balance between engineering effort the things like quality or feature sets.
- Aeolun 2y ago
  I don’t think biz is in any position to decide that. They can tell us when something needs to be delivered by, and we can decide which corners need to be cut to achieve that.
- bee_rider 2y ago
  The IEEE code of ethics https://www.ieee.org/about/corporate/governance/p7-8.html https://www.ieee.org/about/corporate/governance/p7-8.html Would seem to preclude working on a site, like Facebook > 1. to hold paramount the safety, health, and welfare of the public, to strive to comply with ethical design and sustainable development practices, to protect the privacy of others, and to disclose promptly factors that might endanger the public or the environment; Given that sites like Facebook have been used to spread medical conspiracy theories (health of the public), the whole business model is privacy violations, and the site was used to enable the Rohingya massacre (safety/welfare of the public), https://www.pbs.org/newshour/amp/world/amnesty-report-finds-facebook-amplified-hate-ahead-of-rohingya-massacre-in-myanmar https://www.pbs.org/newshour/amp/world/amnesty-report-finds-... But I mean an ethical engineer wouldn’t get in the way of a place like Facebook because they wouldn’t work there in the first place.

mook 2y ago

And sometimes — quite a lot of the time, in fact — never fixing it is the way to go. It sucks, your users will keep complaining about it, and it'll nag you at the back of your mind forever. But if fixing things properly means somebody else ships first and you have no users and you get cancelled, that bug still wouldn't have been fixed. But sometimes your product is so buggy nobody wants to use it. It's all trade-offs, just like… well, engineering.