Live data from Hacker News

Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

web.mit.edu

111–120 of 274 posts

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#111
post #100

Couldn't help noticing: In other words, it’s not just a tool problem, any more than it’s a human resources problem or a leadership problem. Instead it is a systemic problem [...] Shades of an LLMism, a bit padded, a quarter of a century ago. These days someone could easily give it a stink-eye. I'm sure that training has ingested this along with countless similar examples.

That should really be a cautionary tale for everybody accusing everyone of LLM manufacturing texts. Many people write like that. The self-censoring nowadays to try to avoid sounding like an LLM is really sth we need to grow out of.

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#112
post #17

I've been in those companies where "struggling departments" ended up getting all the praises and raise in budgets the following quarter because of the heroic saves they did, and raising awareness on how important they are... For stuff they totally caused on themselves. Meanwhile, my perfectly purring department was struggling to keep the lights on. It's a serious problem in this industry due to the disconnect between…

By building pain into the system. If your hands dealt with injury directly without sending pain signals up to your brain, you'd never change the behaviour that led to that harm or reconsider your priorities. Like it or not, sometimes the best thing for an organisation isn't to just fix every problem and prevent it from bubbling up; it needs to be treated like a learning opportunity for org leadership, which means sen…

> By building pain into the system. If your hands dealt with injury directly without sending pain signals up to your brain, you'd never change the behaviour that led to that harm or reconsider your priorities.

I don't think that's it. Emergent problems require attention and action from leadership, who in turn can make the problem visible to higher ups. This creates signal, and positive feedback when the problem is fixed or mitigated.

If the problem doesn't exist to begin with, there is no signal. Managers don't get to show their fast-acting skills, and there are no heroics to speak of.

So ultimately poorly maintained and managed projects who deliver fixes for problems of their own doing create a perverse incentive, whereas no one is lauded or promoted for doing normal day-to-day things.

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#113

This is exactly the problem with the nature prevention. When it's well done, it seems like nothing was done.

When Covid started, our local government was very clear from the start in saying "If people think we have over reacted, then that means we have done a good job." Alas, that doesn't always fly with the populace.

Trouble is that it is not always true either. You can legitimately overreact and in hindsight it can be hard to distinguish between these two things.

Plus, even if you did overreact, that can still be the better side to have erred on, in moderation.

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#114
post #74

Earlier quoted context omitted.

By building pain into the system. If your hands dealt with injury directly without sending pain signals up to your brain, you'd never change the behaviour that led to that harm or reconsider your priorities. Like it or not, sometimes the best thing for an organisation isn't to just fix every problem and prevent it from bubbling up; it needs to be treated like a learning opportunity for org leadership, which means sen…

The problem is it's systemic. Ultimately, pain needs to come from outside. As long as society rewards incompetence, we'll have incompetent organizations.

No it does not need to come from the outside. If you're an underfunded IT department and your network has an issue twice a week, you will get that funding. If you're heroically obscuring the fact that things are falling apart you won't. That means even if you could somehow, heroically fix it, it isn't perceived as such if nobody ever felt the problem and saw you fix it.

This is a pain signal. Some IT dude saying things are crap in every meeting is not.

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#115
post #102

Ian Rush said it best: "It's best being a striker. Miss five, score the winner, you're a hero. The goalkeeper plays a blinder, lets one in, and he's a villain." Every place I've worked rewards the firefighter over the person who made sure nothing ever caught fire. And the worst part is the math is obvious to everyone except the people who set the incentives.

How would you set the incentives, though? Almost by definition, it's hard to reward things that aren't visible.

Note that there is also the flip side of the coin, people who spend all their time worrying about things that never happen, so it's not like you can just reward a defensive attitude things are more complicated than that.

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#116
post #6

Article published in the Summer 2001 edition of California Management Review, yet it never mentioned Y2K, the first thing I thought of when I read the line "fixing problems that never happened". Perhaps it was actually written in 1999 and took a while to get published, because otherwise that seems a very strange omission. The Y2K problem was very much over-hyped by the American news media at the time (no, at no point…

>no, at no point would airplanes have been falling out of the sky The assertion may have been unfounded, but I think it's just as unreasonable to assert the opposite. Bugs have cascading effects and in a sufficiently complex piece of software they can create chaos with unpredictable outcomes.

The one case I'm aware of where a software glitch did cause a plane crash, there was pilot error compounding the problem. Air France flight 447 was an Airbus A330 flying from France to Brazil, and while high over the Atlantic, the software recorded inconsistent data in its airspeed measurements. (The official crash analysis team concluded that the inconsistent data was likely due to ice crystals blocking the pitot tubes on the plane). The inconsistent data made the autopilot disengage. Pilot error then caused a stall. One pilot then tried the correct move to recover from a stall, pushing forward on the stick to nose down and regain speed. The other pilot was pulling up on the stick to stop the dive, not realizing that that's exactly the wrong thing to do in a stall (or more likely forgetting his training due to panic; he had a lot less experience). The flight software, receiving inconsistent inputs from both controls, averaged the inputs, resulting in zero change in pitch. (It also sounded the "Dual Input" alarm, but the pilots were too preoccupied with their own controls to figure out what that meant at first, and by the time they figured out what was going on it was too late to recover before the plane hit the water).

https://news.ycombinator.com/item?id=4224707 has some discussion of the events, including the fact that the control design (where each pilot has an independent stick) was part of the problem. On a design like Boeing uses where both sets of controls move together, the experienced pilot would have noticed the less-experienced pilot pulling up on the stick because his own stick would be moving, and he would have said "No, nose down." And if they had nosed down to recover speed while still high enough in the air, they almost certainly could have regained control of the plane and saved 228 lives (including their own).

So in retrospect, I think my first sentence was wrong. The software did not glitch, it did exactly what it was supposed to do. It was pilot error that caused the initial stall, and multiple pilot errors that caused the failure to recover from the stall.

There may be examples of software error that has caused planes to fall out of the sky, but I don't know of any. The only plane crashes whose cause I know were due to hardware failure or pilot error, usually a combination of the two.

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#117

I began migrating from network/hardware/IT work and into marketing after nearly 2 years of heavy lifting getting ready for Y2K. In the end, "nothing happened," so all that time and money was wasted, according to nearly every company I worked with. Even had one demand a full refund. I agreed as long as I could revert all the work that I had done. They agreed, and the next day after that their entire system collapsed.…

Idk I joined the field only like 5 years ago. Prior to knowing about programming I had a lot of respect for programmers and tech as it was this magic world to me. After having joined the field the magic is completely gone and I don't want to talk to programmers irl anymore because of how many insufferable people I've met so far. The parts where I've got credit are the simple things, fix printer, fix computer issue A,B and C or small apps like an ad free Sudoku for android which I have built for my friends. The parts I don't get credit for are the parts I get paid for. But I can see that in many industries, as soon as money is involved people are less thankful because they expect you to fulfill your part of the contract. Generally people not knowing shit about tech think that devs sit in HO all day working only 30 minutes. AI didn't help that image.

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#118

Aka: * https://en.wikipedia.org/wiki/Preparedness_paradox

My favorite example is the introduction of speed limit on some accident-ridden stretch of the Autobahn north of Berlin. After introducing the speed limit, the accident numbers went down dramatically. What did the local administration decide? Remove the speed limit again -- cause there were no accidents anymore!

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#120
post #116

Earlier quoted context omitted.

>no, at no point would airplanes have been falling out of the sky The assertion may have been unfounded, but I think it's just as unreasonable to assert the opposite. Bugs have cascading effects and in a sufficiently complex piece of software they can create chaos with unpredictable outcomes.

The one case I'm aware of where a software glitch did cause a plane crash, there was pilot error compounding the problem. Air France flight 447 was an Airbus A330 flying from France to Brazil, and while high over the Atlantic, the software recorded inconsistent data in its airspeed measurements. (The official crash analysis team concluded that the inconsistent data was likely due to ice crystals blocking the pitot tu…

I think your conclusion is upside down. Air safety is based on the "Swiss cheese" model. Multiple layers of safety nets are in place to compensate for issues in one layer. In particular, technical safeguards are there to prevent disasters if the human in the loop makes a mistake which will eventually happen. Any weakening of any technical safeguard makes the system less safe. No matter if the human ultimately made a mistake -- the technical system failing contributed to the accident just as much.
Post reply on HN