Just had to get my barb in for Doze, heh heh. And support RR.
The "IT People" (actually real-time systems architects and engineers, and among the best in their field at the time) simply implemented a set of specifications from the aeronautical engineers, who themselves consulted with pilots, in exactly the same way that electromechanical engineers have always done in aviation.
Philosophically speaking, the computer specialists only dealt with the "How" - the "What" came from the same people it has always come from.
Basically, Doze has it right, to a point.
As a systems engineer after I hung up my g-suit, I wrote the specs and the sfwe folks "coded" it. None of the sfwe "engineers" in my company knew squat about aero or mech or actual piloting. No big deal. They were used to dealing in "abstracts" and sfwe design, not a physical system that was to be implemented or simulated in sfwe.
I was their worst nightmare!
I was an aero/EE guy from school, and was a no-kidding pilot with no small amount of experience in various jets. I had also done sfwe work for a few things during my career as a pilot.
I had to explain frame rate requirements due to hysteresis of the mechanical gyro/gimbal platforms and seeker heads of missiles. The old analog systems did the trick via their basic design and had negligible lag as the digital systems had with their frame rates. So we "smooth" the data for control and display. Big deal. But we also had to deal with real world body rates and maybe tgt motion for a weapon and so on. So some functions had to run at very high frame rates while others could lope along at 10 Hz.
enuf background.
As RR says, a finite state machine will react to inputs with very deterministic outputs/actions. That was my company's philosophy for armament control and display systems, and our designs were very easy to validate thru testing. The good news was our systems were easy for the human operators to understand and operate. Our sfwe was not trying to be "intelligent", and "guess" what the human wanted to do.
So I have to throw my lot with the folks that postulate the AF447 crew was presented with conflicting displays and aircraft reactions to their control inputs, and they did not know with certainty what was really happening. Further, their training seemed to emphasize all the FBW protections and the cascade of control law reversions that attempted to retain bank angle limits, pitch angle limits, AoA limits ( read Alpha prot), mach/overspeed warnings, etc. Sheesh!!! Think you would be confused?
Make no mistake, I do not advocate a simple, direct control of the various aero surfaces such as some here believe would save the day. Even the old, old mechanical systems used mechanical/hydraulic components to limit surface deflections and their rates of deflection.
My problem has always been with the "autopilot" type functions and protections that seem inherent in the 'bus FBW design and its reversion modes. For Chrissakes, the jet seems to be extremely stable and docile. Without the autopilot engaged, it should handle just as any large jet. It should also handle well if airspeed/ "q" inputs are lost. But this is where training enters the equation. How does the jet "feel" when most of those "protections" are gone? And worse, what "protections" are still there? So there needs to be a clearly defined reversion sequence that the pilots are trained to deal with, and the more simple, the better, The finite state machine RR and I refer to.