"Your analogy does not hold for aviation."
It doesn't hold for software engineering either. And given that most modern aircraft systems are the product of software engineering it's a worry.
I've run dozens of young bright programmers who think the software tools and environment they worked in was foolproof. Anything dot net and Java and it must be good!
Actually that's totally false. In reality almost all software generated on these types of systems is not deterministic nor foolproof. For time critical applications like machine control they are worse than useless.
Luckily, I assume, modern aircraft control systems use real time executives with deterministic software languages - i.e. no garbage collection and very precise timing available.
Sadly though the people who code this stuff are trained at university in the soft languages and from what I can see have no idea about reliable, efficient and/or elegant programming. As a result there is a massive amount of program specification required to compensate plus massive amounts of test cases. My experience is that most code can be programmed to meet the test cases - and then can be expected to fail outside the test-case environment.
The A330 upset near Learmonth was an example where the software and system test cases failed and critical timing issues suddenly came into play.
Almost certainly having a crusty old programmer used to working on bare iron in C or C++ would be a better option. They've had years of seeing all the different ways software and systems can stuff up and so are far better placed to design and write conservative bullet-proof code.