661–670 of 773 posts
I was responsible for safe for flight inspections on military aircraft and the photo included in that post is completely insane to me. Those bolts being loose (and they are BIG bolts) would mean multiple people in the installation process didn’t do their jobs, and signed their life on the line saying they did. When I did maintenance, there was someone (QA) there to witness every torqued bolt, inspect every safety wir…
Earlier quoted context omitted.
I agree. I’m regularly critical of Boeing Defense (particularly space contracts where I’m a huge Boeing skeptic), but I think people are pretty off base if they think Boeing is just completely incompetent. Airliner safety is insanely good. Just vast seas of competence, but when there’s a super rare failure, the incorrect impression people get is that Boeing (or Airbus) is just full of incompetency. Almost nothing tha…
Being better then driving shouldn't be the standart. Specially driving in the US. Flying isn't safer then trains I would assume. Flying has the advantage of being seperated from almost everything else. Most accidents happen when there is mixed traffic, specially cars operated by people with minimal training.
Earlier quoted context omitted.
You're joking but it's the real meaning conveyed to their customers, the airliners.
Yeah, that's why the leading low-fare airlines (Southwest, Ryanair) love it - so it's up to the customers to say that they no longer want to fly with an over 50 year old design that was initially a regional airplane but is now being used for transatlantic flights.
Bolts and machine screws are very interesting. One mistake I, an amateur bike mechanic, made for years was not greasing bolts properly before assembly. It sounds counterintuitive but without grease a bolt (or machine screw) will bind early with a high torque well before it is correctly tensioned lengthways. The torque is just a proxy for the tension and it is this tension which is needed to fasten your components tog…
I was responsible for safe for flight inspections on military aircraft and the photo included in that post is completely insane to me. Those bolts being loose (and they are BIG bolts) would mean multiple people in the installation process didn’t do their jobs, and signed their life on the line saying they did. When I did maintenance, there was someone (QA) there to witness every torqued bolt, inspect every safety wir…
Clearly this is hyperbole.
Earlier quoted context omitted.
I expect even at its worst, software development could learn a lot from aircraft QA. Especially since most shops have pretty much tossed professional career QA out the window.
I work in the defense industry, it’s very much like the aerospace industry in that we deal with human life as a consequence of our work. We have software QA departments that operate very much like manufacturing or aerospace QA. Software QA provides nothing of value to software development; having it as a dedicated function works against the overtly stated goals of the function and counterintuitively acts to degrade q…
> To give an example of how these dynamics destroy quality in software. I once found a bug in software on a piece of test equipment where a logarithmic search function was not operating on a strictly sorted list. When I pointed this out to my leadership I was told that if we changed any part of code, it would require a new FQT, which would be too expensive to conduct and was not in the budget. Although the bug would have been trivial to solve, and was clearly wrong and would not provide any benefits by remaining in the test equipment software, the process required for changes prevented solving the issue.
I've seen this happen where it was a bad thing, but also where it was a good thing.
It's all about risk.
What risk does the software defect pose to the mission? What risk is inherent in making any change to the software? Noting that even trivial changes can be fat-fingered and thus are a source of risk. I've seen it go wrong this way: a seemingly trivial change was made, but the developer accidentally checked an extra file into source control, causing a further defect.
And then: what is the cost of mitigating these risks? Maybe the software defect is as trivial as its fix. Maybe an acceptable fix would be to write up a workaround in the documentation.
I don't think it's always wrong to say no to fixing issues. I also don't think it's always right that a separate QA department contributes nothing to the organization, even if they act as a handbrake on the software developers (sometimes, precisely because they do that). Human factors are real.
Which is more likely: * Lazy production line worker hand-tightens bolts and forgets to torque them, faking the results on the electronic torque wrench (which records the tightening of every bolt). * A design flaw causes vibrations which cause these bolts to loosen.
> Lazy production line worker Because of your inclusion of the assumed 'lazyness' of the first I assume that you think it's the first? why do you think it's more likely that the line worker is lazy and the one that screwed up? why not the 'lazy' designer who thought it would be strong enough, or 'lazy' supervisors that forget to supervise, or the lazy quality-assurer that forgets to assure quality? Everyone makes mis…
Earlier quoted context omitted.
I work in the defense industry, it’s very much like the aerospace industry in that we deal with human life as a consequence of our work. We have software QA departments that operate very much like manufacturing or aerospace QA. Software QA provides nothing of value to software development; having it as a dedicated function works against the overtly stated goals of the function and counterintuitively acts to degrade q…
> Good software teams build quality into projects by introducing continuous integration, unit testing, creating feedback, and tightening these feedback loops. No. Good software teams are led by competent, technical management. Managers who aren't afraid to get down into the dirty details. Managers who aren't afraid to roll up their sleeves and write code if they need to. The process doesn't matter. The management of…
For some reason, developers seem remarkably blind to the skills other roles and disciplines require. Only a developer can do that, everyone else is basically useless fluff. Maybe it's a form of arrogance or just deep unself-awareness.
Earlier quoted context omitted.
The management imported from McDonnel-Douglas? The same management that drove it to ground? The fish rots from the head. And these constant problems sure do sound like a new company culture of cutting corners instead engineering first.
Looks like the installer did their job poorly and the QA rubber stamped it without checking. Are the QAs required to make photos to prove that they did their job? Like those food delivery people. Alternative is wrong bolts, or sabotage. But more possible - one lazy QA ghosting.
In my experience, no one puts their job on the line over silly reasons like this, unless there is intense pressure (unrealistic deadlines, heavy workload and poor working conditions) that makes mistakes like this inevitable. I wouldn't be surprised if an honest independent review of either company found ridiculous cost-cutting measures and/or emotional overload.