Let's suppose that the entire control logic for MCAS was now re-implemented with vacuum tubes. Would you now argue that the aircraft crashes indicate a hardware problem? Or would you agree that the real problem is in the system design, since any conforming implementation of it will produce the jeopardy?
If it was implemented with vacuum tubes, that would indicate a hardware problem as well as a system design problem.
So in this situation, the claim is that braindead contractors mechanically implemented something to spec by force of law? Sure, then whoever designed the logic is accountable.
In 99.9% other environments, the distinction is collapsed because the implementor typically has responsibility to design sub-component level logic correctly, to high-level requirements, but also to overall business need and in service to even higher level project goals, and the team that designed the logic is also implemented by the same team.
nope, all of the vacum tubes would be working as designed. not a hardware problem, a system design problem.
thus the invention of a discipline called 'systems engineering'..
i would say in 100% of engineering development, the design is done as a system, and specific requirements are allocated to design elements (like MCAS software). Each of these elements is tested against the requirements.
aeronautical engineering is a very specific skill. so is aircraft controls. so is airworthiness. a software engineer is an expert in software, not these other disciplines.
At the level of specification you've laid out here, the act of 'software development' is reduced to almost nothing, and you have re-categorized the entire effort as systems engineering.
Having a specification for how a system should behave in response to various input signals is not at all the same as actually having the functioning software for achieving that system.
In fact, achieving a functional and fully correct piece of software based on such a specification is not at all a trivial task, as experienced software engineers will well appreciate.
Because while the specification may describe a certain sequence of inputs that should result in a certain sequence of outputs, it probably does not prescribe the exact data structures, memory layout, logic flow, and computational steps required to guarantee the correct output is always produced from a given set of inputs.
And the people being paid to create the necessary data structures, algorithms, calculations and control logic in order to implement the design specification... those developers are specifically not in a position to make systems design engineering changes to the underlying specification itself.
Software engineering as a field has accomplished so much in terms of quick iterations and low-friction paths to products that I think it has become lost that there are established ways to establish a safety case in a technical manner. Modern software engineers have achieve this speed, largely, by choosing not to apply the level of rigor in process that you describe. This is usually ok, because most software projects do not require that level of rigor (until the costs are too high not to, like AWS, which formally specified critical parts of their infra in TLA+ before software and IT people implemented it).
I think the parent post is an example of this problem taking on flesh. It has been so long since we realized the folly of over-specification in most projects that we have lost memory of there being cases where having a body of people engineering the system and specifications distinctly from the people who implement them actually does matter a great deal.
As a software engineer and not a systems engineer, I thank you for your comment. It has great clarity.
HN folks here seem hesitant to say this.
But without the dumb ability to do repeated activations it would've been a much less severe problem.