kind of depends on how you name it. my understanding is the code 'worked per requirements', meaning it did everything that it was supposed to, as defined by the requirements allocated to it.
for things like this, there is a layer of 'systems engineering', that decides (hopefully using an engineering process) how the airplane will work. this is codified into a 'specification', that is then handed over to software to implement.
if you are a software engineer given this task, you implement it per the specification. nothing more and nothing less. of course, if you have a concern, you bring it up (both informally and formally). there is no 'discretion' by the programmer.
The number of AOA sensors, how much control authority, how often the inputs are applied, are all decided by systems engineers (with aeronautical engineers input and analysis). the software engineer cannot 'second guess' if AOA failure has been considered and change the implementation.
for things like this, there is a layer of 'systems engineering', that decides (hopefully using an engineering process) how the airplane will work. this is codified into a 'specification', that is then handed over to software to implement.
if you are a software engineer given this task, you implement it per the specification. nothing more and nothing less. of course, if you have a concern, you bring it up (both informally and formally). there is no 'discretion' by the programmer.
The number of AOA sensors, how much control authority, how often the inputs are applied, are all decided by systems engineers (with aeronautical engineers input and analysis). the software engineer cannot 'second guess' if AOA failure has been considered and change the implementation.