Live data from Hacker News

United finds loose bolts on plug doors during 737 Max 9 inspections

theaircurrent.com

771–773 of 773 posts

Re: United finds loose bolts on plug doors during 737 Max 9 inspections

#771
post #769

Earlier quoted context omitted.

> DEI is a racist agenda that endangers us all. The argument so far has shown how fallacious and unsubstantiated this claim is. The irony in this case is that the exact opposite applies. > It should be discarded for a merit based approach that ignores race, religion etc. This so called 'merit' is a distraction meant to hide 'privilege'. There is no merit unless privilege gap is addressed first. If you think DEI hirin…

> The argument so far has shown how fallacious and unsubstantiated this claim is. The irony in this case is that the exact opposite applies. Once you get out of the wacky humanities courses and into the real world this argument falls apart. Look at the aforementioned UA incident. > This so called 'merit' is a distraction meant to hide 'privilege' We'll have to agree to disagree on that one. > My original reply had no…

[deleted]

Re: United finds loose bolts on plug doors during 737 Max 9 inspections

#772
post #575

Earlier quoted context omitted.

Fair point, you are correct in your inference that there are some bad actors in my workplace. However, I’ll argue that the fundamental dynamics of bifurcating the responsibility of quality from software leads to a steady state where all QA departments end up as a liability shield given enough time. This is driven by Pournelle's iron law of bureaucracy [1], which says that people who promote the bureaucracy rather tha…

I have seen a case of Software QA taking a very different shape, so I'd like to argue that the outcome you describe is not intrinsic to software QA, but rather to company culture. The case I'm talking about does not have a separate QA department, but QA people as part of every software team. If a product fails, that team is responsible, so software devs are in the same boat as QA. They focus on learning from these fa…

I can see integrated QA working for teams because QA personnel would understand project specific constraints and degrees of freedom and tailor solutions in a way that top-down QA cannot.

However, there are situations where less QA may be needed, for periods of time, such as when PRs may be low. QA may be seen as overhead by management, and something to reduce. This will lead to QA shared between teams and a push for standardization and top-down process deployment to minimize complexity for these personnel will develop. Complexity to manage the QA personnel will be shifted to development teams.

This situation absolutely is controlled by company culture. A culture that neither values QA nor development will do this. A company under financial strain will do that. Companies wax and wane constantly.

Re: United finds loose bolts on plug doors during 737 Max 9 inspections

#773

Earlier quoted context omitted.

Fair point, you are correct in your inference that there are some bad actors in my workplace. However, I’ll argue that the fundamental dynamics of bifurcating the responsibility of quality from software leads to a steady state where all QA departments end up as a liability shield given enough time. This is driven by Pournelle's iron law of bureaucracy [1], which says that people who promote the bureaucracy rather tha…

But what makes 'software QA' fundamentally different than 'non-software QA' to give it the problems you foresee?

Fundamentally different problems.

Manufacturing process builds identical widgets using standard equipment. Widgets are inspected to confirm they are within spec. Frequentist statistics are used to determine when widgets are consistently out of spec. When this happens, equipment is inspected and repaired as a corrective action. This process is well defined and linear.

Software produces bespoke, non-standard widgets to address domain specific needs. At the end of the day, software developers are defining a process for machines to follow. If you want to control quality in the software development , aside from having perfect domain knowledge for a particular project, the only way to do it do it is to define an arbitrary process for developers to follow and track adherence to it. This may have no impact, or be a hindrance. It will never add value because it will never be abstract enough to be appropriate for every domain.

Post reply on HN