@aim9xray Perhaps I should clarify. My trade is programming, the demand for new systems rarely originates with the end-users. In many cases, new technology drives the demand for new systems, because it offers new possibilities, financial, functional, operational or maintenance-wise. A responsible group of Computer Science weenies will wish to gather information from as much of the fields of expertise that matter.
Some of that information, some of it crucial, resides in, among others, end-users. Us weenies ignore them at our peril. Whoever cuts us off from that source of information needs a bloody good reason for that cutoff.
While there is a need for end-user input, I'd throw a big caveat into this. On a big project the average coder has little need for contact with the end-user. I'm not sure I ever talked to an end-user in my entire career. We had the occasional one pass through and do a presentation, but contract level, even engineering-level discussion, not my department. OTOH if you consider the customer's QA engineers the end-user then I had them leaning over my shoulder for years at a time. Give us a set of flight control laws, or a tweak to those rules from flight-testing, and it's just a case of cranking those equations into code, but for a lot of the stuff involved in multiply-redundant, real-time, safety-critical software, we were the experts, not the customer*. The end-users would barely know what the penal system (to pick an example) was, the customer would only know they had specified a certain level of redundancy, but designing it, implementing it and debugging it, that was what we did day in, day out. (The penal system was our way of managing redundancy, and it's not just Box X has failed, but situations like "Box X has failed and now Boxes Y and Z disagree, what do we do?"**)
* Doubly so on 777 where the FAA didn't really know what they were doing WRT FBW systems.
** And then multiply that for three sets of three boxes, plus ancillary stuff like ADCs.
My impression is that F-35's software problems have nothing to do with coding per ser, or contact between the coders and end users. I think the entire computer architecture is problematic, it's over-integrated, it massively multiplies the degree of integration testing needed, and, as we're currently seeing with TR-3, it means everything is tied to the progress of the slowest element. There's clearly power in sensor fusion and throwing massive computing resources at what you're doing with it, but that doesn't mean you have to tie every single computing system in the aircraft into one monolithic block. Over and above being problematical in itself, it means you can't justify smaller upgrades because of the amount of integration required and that drives you into combining changes into larger and larger changes, which then require unmanageable levels of integration testing.
(And to paraphrase a remarkable foreword in my copy of the MISRA C guidelines, 'If you're going to do a massively integrated safety-critical system, we'd really rather you didn't do it in C....' C has just too many ways to
enable stupidity go subtly wrong).
