Hacker News Reader

Comment by mannykannot | Hacker News Reader

I do not wish to diminish how serious any tampering with the evidence would have been, or of Boeing's more general attitude of dismissing signs that there was a problem with the equipment, but it is not entirely clear from the article that someone from Boeing removed the Colorado Springs PCU spring and end cap. The article says the item had apparently been in the possession of United Airlines and valve designer/manufacturer Parker Bertea before their absence was noticed. The unit is also described as having been heavily damaged in the crash, to the point where several other parts had to be replaced before it was tested.

View on HN

Boeing's more general attitude of dismissing signs that there was a problem with the equipment

Having worked in software for decades, I've noted a particular sort of bias in myself and other developers. We tend to feel that our creations are like our children, and we are far too ready to blame the user. I've caught myself doing this. I've been caught out by QA doing this. I've caught fellow developers doing this, where I am in the position of the user. On that last count, I'm still surprised at the unrealistic levels of incompetence and/or malice ascribed to me in support of those face saving theories.

Emotions are a tricky thing. Do not formulate theories in the heat of them. If you care about being truthful, be especially mindful of your incentives in those moments.

That's why dogfooding is so powerful. The best way to first hand experience the shortcomings of your product is to use it. This makes me wonder if anyone at Google is using G-Suite themselves.

The effect of dogfooding is limited though: when you know all the quirks you won't when notice that you constantly work around them.

when you know all the quirks you won't when notice that you constantly work around them.

Unfortunately, we programmers are particularly good at doing this. We are extremely good at being "nice" to software. ("Mechanical sympathy")

My child has bypassed the lock screen on my laptop and caused a gray-screen-of-death, just by banging on the keyboard. I saw it, I am unable to replicate it. Everything should be tested by a child before it can enter production service.

My kid subscribed me to Apple Music by playing with the apple tv remote...

Human-powered fuzzing! As a parent of three kids under 6, I wholeheartedly endorse this.

I know exactly what you mean - from toggling a mode on a mechanical keyboard I didn't know existed and spent 20min looking for how to turn it off, to managing to delete several Powerpoint slides that were not on the screen at all, solely via keyboard (so that I didn't notice it until saving/closing the file and losing them forever). It's amazing :)

I recall a kids game where the game exited when the spacebar was touched. It was pretty exasperating, because the kiddies couldn't figure out how to get the game running again.

For most Googlers it's all they use...

Doesn't matter if the devs know it's broken, if the managers decide it's not worth paying to fix.

I’ve used software that’s so bad and thought there’s no way anyone at the company that made this has ever used this.

Nearly everyone at Google uses GSuite.

Arguably, not enough people at Google use the competitors stuff. The employees are sitting there thinking they're making a great minidisc player while the rest of the world has moved on to streaming audio...

In my experience end users are very often wrong, QA departments are rarely wrong. If pilots are saying I pressed the rudder and it didn't move healthy skepticism may be needed, I'd hazard less skepticism than for an average end user as the pilots are presumably highly skilled users of the product. But if after very thorough investigations a large group of pilot reports and the NTSB are telling you something is wrong then you should assume that something is wrong and do your best to prove it otherwise.

As you note emotions, and frankly legal liability, play huge roles in this realm. Worrying about legal liability might be harder to tame but in my experience it is easier to disabuse yourself of the notion that you can do no wrong.

In my experience end users are very often wrong, QA departments are rarely wrong.

This is true. However, even in the cases where I have spent considerable time analyzing the situation and have included specific information, I get the distinct impression that devs simply don't listen to what users say. I get the distinct impression that most of them simply disdain me and don't even listen to what I have to say.

The cases of "surging" where people claimed they were pressing hard on the brake when the car lept forward come to mind. (The most credible explanation is they put their foot on the gas instead, or are simply trying deflect blame away from themselves for the crash.)

That's not the most credible explanation.

http://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_s...

I don't buy it. Heck, I've even stepped on the gas instead of the brake. Besides, the brakes are much more effective than that little Toyota engine is. Try it yourself. Go full throttle and step hard on the brake. You'll stop.

Look at slide 8.

With wide open throttle, why would the power brakes lose vacuum? Vacuum is lost when the engine quits.

Besides, just to stand on one foot requires 100 lbs of force exerted on your foot. If you can walk, you can do that. Pressing with 175 lbs is not a problem.

The point is, the brakes can override the engine torque. Unless, of course, you're standing on the gas instead of the brake.

You can also just turn the key off on a runaway engine.

Reply on news.ycombinator.com