6 ms·

Often times as a Software Developer I encounter a bug which has an obvious two line fix. Rather than implementing that though I often spend another few minutes

Often times as a Software Developer I encounter a bug which has an obvious two line fix. Rather than implementing that though I often spend another few minutes digging into how and why that bug was introduced. Often times I'm left with a greater understanding of the problem or encounter a requirement that the previous developer was trying to implement that my fix would have broken. Other developers will simply assume the previous developer was an idiot and bash in the fix. I feel like in this case a lot of people are assuming the engineering team were idiots, or criminally trying to make an aircraft which didn't pass safety standards. Rather than taking a look at what caused the bug in the first place.

deleted 8y ago
[deleted]
thatswrong0 8y ago
It sounds additionally like the bug, caused by the issues presented in the tweets, made it past the usual safeguards and into production because of an abnormal certification process: https://www.seattletimes.com/business/boeing-aerospace/failed-certification-faa-missed-safety-issues-in-the-737-max-system-implicated-in-the-lion-air-crash/ https://www.seattletimes.com/business/boeing-aerospace/faile... So there were failures at almost every level it seems.
- JorgeGT 8y ago
  Wow... thanks for the link. The details are highly troubling. They assessed the safety of the MCAS based on a statement saying it had max. authority of 0.6º, being thus permissible to rely on a single sensor for this system. But in fact it had an initial authority of 2.5º, which is already pretty high by itself, and then that authority increased after each activation until full stabilizer deflection. That they implemented such a high authority system without triple sensor redundancy and without briefing the pilots is just insane.
  - im_down_w_otp 8y ago
    Yeesh. If true, it seems like it should have been a 3oo4 system, with added heuristics for handling soundness of the sensor inputs, and with easy override defaults (e.g. control surface override) and auto-disable on disagreement. What I don't get is how this drifting compounding boundary condition wasn't caught during formal modeling?
    - sitkack 8y ago
      We don't do enough adversarial testing. We are increasingly reliant on systems that have poor closed loop behavior with little to no memory. We need to design systems that are redundant, that have short and long term memories and have domain knowledge to compare their internal understanding of the universe with. And these autonomic systems need to alert the operators on what they are doing, why they are doing it and how to turn it off.
- e40 8y ago
  > So there were failures at almost every level it seems. They aren't failures, they were designed in. There are forced at work, since the 80's, that have been trying to kill effective government institutions because they are seen anti-free market (the exact quote was "My goal is to cut government in half in twenty-five years, to get it down to the size where we can drown it in the bathtub."[1]). This is the end result, as are E-coli outbreaks, etc. The government is being made ineffective so people can stand and point "see, I told you so, and we need to move this to the private sector were it will be done properly." [1] https://www.brainyquote.com/quotes/grover_norquist_182534 https://www.brainyquote.com/quotes/grover_norquist_182534
  - thatoneuser 8y ago
    To be fair there has been plenty of incompetence in the government. I mean as this or the 2008 financial crash shows us - total free market is folly, but there's some back and forth discussion to be had on how much government is good.
jaclaz 8y ago
>Often times as a Software Developer I encounter a bug which has an obvious two line fix. Rather than implementing that though I often spend another few minutes digging into how and why that bug was introduced. Often times I'm left with a greater understanding of the problem or encounter a requirement that the previous developer was trying to implement that my fix would have broken. >Other developers will simply assume the previous developer was an idiot and bash in the fix. That is exactly the case of Chesterton's fence (JFYI): https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence
rlabrecque 8y ago
I deal with this constantly. Someone gets a bug report for a crash, let's say a null pointer dereference, so often I see: > if (pPointer == nullptr) { return; } > Crash is fixed! I mean sure... but that's not the problem. Why was pPointer null here in the first place? So few people take the time to understand that :(
- aphextron 8y ago
  >So few people take the time to understand that :( Because "fix this null pointer exception" is ticket number 14 this week, and your PM just wants it checked off. They don't want to hear that you need another week of digging through layers of spaghetti to track down the source; that doesn't bode well for their KPI goals. This is a systemic issue in the way software companies function.
  - quickthrower2 8y ago
    We can blame management but sometimes the developer just doesn’t give a f* or it doesn’t fit their agenda. I guess both are ultimately management issues, but it’s a shared responsibility.
    - deleted 8y ago
      [deleted]
    - thatoneuser 8y ago
      Ultimately it doesn't matter if your engineers don't give a fuck if management will sabatoge their efforts when they do care. Only if you have management who won't forgo quality for ticks can you really blame the dev.
- janpot 8y ago
  OMG, yes. Every time I see this in a code review I go "why is this receiving a null here?" And 90% of the time I get back "dunno, I saw null pointer exceptions in the logs"
  - 8y ago
peteradio 8y ago
I haven't seen anything blaming engineering for these problems, although I'm not saying those comments aren't out there. I think the impression I get is that Executives and Regulators are to blame. Engineering generally isn't in a decision making capacity, they are given problems and provide solutions in a pretty compartmentalized role. Sure they could have resigned if they had known what it was leading to (and perhaps that happened) but that is about the extent of pressure they can exert in these situations.
quickthrower2 8y ago
> Other developers will simply assume the previous developer was an idiot and bash in the fix. I think it’s worth avoiding working in teams with devs that do that. It’s a nightmare. The only excuse is an inexperienced dev, and this should be picked up during code review and they are told why it’s a bad idea to chuck in fixes without considering surrounding code.

deleted 8y ago

[deleted]

thatswrong0 8y ago

It sounds additionally like the bug, caused by the issues presented in the tweets, made it past the usual safeguards and into production because of an abnormal certification process: https://www.seattletimes.com/business/boeing-aerospace/failed-certification-faa-missed-safety-issues-in-the-737-max-system-implicated-in-the-lion-air-crash/ https://www.seattletimes.com/business/boeing-aerospace/faile... So there were failures at almost every level it seems.

JorgeGT 8y ago
Wow... thanks for the link. The details are highly troubling. They assessed the safety of the MCAS based on a statement saying it had max. authority of 0.6º, being thus permissible to rely on a single sensor for this system. But in fact it had an initial authority of 2.5º, which is already pretty high by itself, and then that authority increased after each activation until full stabilizer deflection. That they implemented such a high authority system without triple sensor redundancy and without briefing the pilots is just insane.
- im_down_w_otp 8y ago
  Yeesh. If true, it seems like it should have been a 3oo4 system, with added heuristics for handling soundness of the sensor inputs, and with easy override defaults (e.g. control surface override) and auto-disable on disagreement. What I don't get is how this drifting compounding boundary condition wasn't caught during formal modeling?
  - sitkack 8y ago
    We don't do enough adversarial testing. We are increasingly reliant on systems that have poor closed loop behavior with little to no memory. We need to design systems that are redundant, that have short and long term memories and have domain knowledge to compare their internal understanding of the universe with. And these autonomic systems need to alert the operators on what they are doing, why they are doing it and how to turn it off.
e40 8y ago
> So there were failures at almost every level it seems. They aren't failures, they were designed in. There are forced at work, since the 80's, that have been trying to kill effective government institutions because they are seen anti-free market (the exact quote was "My goal is to cut government in half in twenty-five years, to get it down to the size where we can drown it in the bathtub."[1]). This is the end result, as are E-coli outbreaks, etc. The government is being made ineffective so people can stand and point "see, I told you so, and we need to move this to the private sector were it will be done properly." [1] https://www.brainyquote.com/quotes/grover_norquist_182534 https://www.brainyquote.com/quotes/grover_norquist_182534
- thatoneuser 8y ago
  To be fair there has been plenty of incompetence in the government. I mean as this or the 2008 financial crash shows us - total free market is folly, but there's some back and forth discussion to be had on how much government is good.

jaclaz 8y ago

>Often times as a Software Developer I encounter a bug which has an obvious two line fix. Rather than implementing that though I often spend another few minutes digging into how and why that bug was introduced. Often times I'm left with a greater understanding of the problem or encounter a requirement that the previous developer was trying to implement that my fix would have broken. >Other developers will simply assume the previous developer was an idiot and bash in the fix. That is exactly the case of Chesterton's fence (JFYI): https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence

rlabrecque 8y ago

I deal with this constantly. Someone gets a bug report for a crash, let's say a null pointer dereference, so often I see: > if (pPointer == nullptr) { return; } > Crash is fixed! I mean sure... but that's not the problem. Why was pPointer null here in the first place? So few people take the time to understand that :(

aphextron 8y ago
>So few people take the time to understand that :( Because "fix this null pointer exception" is ticket number 14 this week, and your PM just wants it checked off. They don't want to hear that you need another week of digging through layers of spaghetti to track down the source; that doesn't bode well for their KPI goals. This is a systemic issue in the way software companies function.
- quickthrower2 8y ago
  We can blame management but sometimes the developer just doesn’t give a f* or it doesn’t fit their agenda. I guess both are ultimately management issues, but it’s a shared responsibility.
  - deleted 8y ago
    [deleted]
  - thatoneuser 8y ago
    Ultimately it doesn't matter if your engineers don't give a fuck if management will sabatoge their efforts when they do care. Only if you have management who won't forgo quality for ticks can you really blame the dev.
janpot 8y ago
OMG, yes. Every time I see this in a code review I go "why is this receiving a null here?" And 90% of the time I get back "dunno, I saw null pointer exceptions in the logs"
- 8y ago

peteradio 8y ago

I haven't seen anything blaming engineering for these problems, although I'm not saying those comments aren't out there. I think the impression I get is that Executives and Regulators are to blame. Engineering generally isn't in a decision making capacity, they are given problems and provide solutions in a pretty compartmentalized role. Sure they could have resigned if they had known what it was leading to (and perhaps that happened) but that is about the extent of pressure they can exert in these situations.

quickthrower2 8y ago

> Other developers will simply assume the previous developer was an idiot and bash in the fix. I think it’s worth avoiding working in teams with devs that do that. It’s a nightmare. The only excuse is an inexperienced dev, and this should be picked up during code review and they are told why it’s a bad idea to chuck in fixes without considering surrounding code.