While this is meant I think a little tongue-in-cheek, it's always important for everyone to contribute value. QA is vital to the success of any project, if all it is functioning as is a Boolean check at the end that says "good" or "bad" and it keeps spitting out "bad" then it is not providing value.
QA needs to be implemented throughout the process, and it needs to be capable of feeding changes into the system at different stages to make sure that it's providing feedback at the earliest possible moment.
I know nothing about this project, so I don't know what their issues were along the way. Definitely they need real hardware at the end to test with, but I hope that they had mocked out the expected hardware interfaces such that they could have quicker turnaround earlier in the cycle.
If the Emperor has no clothes, and QA keep saying "naked", there is value there. The value lies in highlighting the fact that there's a bunch of advisors that either have been actively profiteering from the fake garment con, or where negligent in their duties and failed to notice the problem before.
Either party would have strong interest to cover up their negative-value-added actions, but since they cannot directly challenge QA statement, they go and say that "it does not add value". In the strictest sense of the word they are true, QA does not add value, it helps prevent/correct that would destroy already-added value in the product if left unchecked.
Which part exactly is bullshit? The "QA is vital to the success of any project", bit? or the "QA needs to be implemented throughout the process", bit?
Because, I'm confused. I quite literally said that QA needs to provide value THROUGHOUT the process to help increase the success (value) of the project. All I said in anyway that disagrees with you, is that it doesn't provide value if it only exists at the END. I can't believe that any modern developer/qa would disagree with that.
The part I disagree with is looking at a disfunctional system, taking the component producing the loudest symptoms and declaring it "non value added".
I agree that, in general, QA needs to provide specific feedback to development in order to accomplish its goals. I disagree with the unstated asumption that the problem with F-35 is a QA problem. I know nothing about planes, but for what I have read online, this has been a basket case of Project Management vices and mispractices.
In my mind, claiming that QA is not adding value in this case is the equivalent of "fixing" your car by clipping the cable that goes to the "Engine Maintenance" led. I agree a one bit message is not enough to actually solve the problem, but ignoring the one bit of information you already have is just wrong.
.. then it's quite possible that the software is bad and not improving. Possibly in a way that will get people killed. Ignoring the quality concerns and carrying on gave us the Challenger disaster (approx 30 years ago today).
Where did I say "ignore"? I'm saying provide earlier feedback in the system such that it's not one big "bad" signal, it should be lots of minor signals, each one easily fixed.
Try to look at the bigger picture. Quality software does not have to come at the cost of development, and development does not need to come at the cost of quality.
QA needs to be implemented throughout the process, and it needs to be capable of feeding changes into the system at different stages to make sure that it's providing feedback at the earliest possible moment.
I know nothing about this project, so I don't know what their issues were along the way. Definitely they need real hardware at the end to test with, but I hope that they had mocked out the expected hardware interfaces such that they could have quicker turnaround earlier in the cycle.