Airbus has invested in applying software verification for a while (https://www.di.ens.fr/~delmas/papers/fm09.pdf). I haven’t seen as much sustained interest in formal verification in industry in the US as I’ve seen in Europe, so I’m guessing this may contribute at least a little to the difference. Fortunately more US companies are starting to take this stuff more seriously.

Which is a bit surprising given Ada, Boeing and Department of Defense.

Maybe this has something to do with it:

"Boeing's 737 Max Software Outsourced to $9-an-Hour Engineers"

https://www.industryweek.com/supply-chain/article/22027840/b...

Hear me out:

So you have millions of Software Engineers flying in Boeing planes every year, right? They could be valuable free labor while in the air!

We just have to modify the in-flight WiFi so all you can do is clone the Boeing monorepo, and for every submitted pull request we give out free SkyMiles or something.

You're overthinking it: just provide access directly into the avionics and develop in production, isn't that what all the cool kids are doing these days?

You know the code quality will be good when their lives literally depend on it.

Well, the Tesla plane is going to be something to remember.

Ah yes, the new job description will be "devpilot", now that free time watching the screens at 30kft can be used productively.

If flying == true goto Landing()

Please delete this before Boeing MBAs get their grubby little booger hooks on it.

> "Boeing's 737 Max Software Outsourced to $9-an-Hour Engineers"

It is not like $200-an-hour engineers do not write crap code.

If your SW department lives in a bubble and testing is optional...

I’ve spent a decade in the public sector where you’ll find a little of both. In my experience the dedicated software departments produce better quality software over time. This isn’t to say you can’t do it with integrated teams spread out over your organisation, it’s just that it comes with more of a risk of two separate teams working “against” each other (usually not on purpose) when you have less “control” over your digitalisation organisation. Now, I’m actually a huge fan of doing the spread out stuff, but not for critical software. The best comparison I have from my work is medical software that has life and death impact. I absolutely think your hospital should have dedicated digitalisation teams spread out over all it’s organisations to better spot and build things that benefit the organisation, but the people writing the surgery automation software need to be in the department that does that sort of thing in my opinion.

What I have experienced to be more of a factor on the quality of your vital software than anything is your corporate culture, however, I’m sure you can succeed with more autonomous teams and with dedicated departments alike, but to do so, the single most important factor is that you let your engineers and their quality decide when things are ready. Your entire organisation needs to understand that no matter what level of CEO you are, your opinion doesn’t matter if the engineers tell you something isn’t safe. And you need to foster a culture where your engineers will actually tell you that things aren’t ready without any sort of incentives to lie or move too fast. Which is incredibly hard to do.

I suspect that AirBus is simply better at this than Boeing. With the amount of scary stories to come out of Boeing in recent years, it sort of looks like Boeing has become a place where money matters more than anything else, so much so, that quality product aren’t as important to them as they once were. Which can frankly happen to any organisation and Boeing can also find its way back from there.

But really, if that happens to an organisation where it costs lives it’s the responsibility of the government to shut those companies down with regulations. Which is something the US seems to struggle with, and many Americans will likely even find this statement sort of appalling.

I've spent almost two decades with complex equipment. In my view it's about functionality. The spread out sw works better because it is there to provide a specific function, requested by people who know what they need and what they are taking about. When you have the almighty software team, they don't understand mechanics, mechatronics, physics, avionics, thermodynamics, electronics, etc. And they end up taking more impactful decisions hidden from all those other people. It can work, but the bigger the product the more difficult it is (also you need very humble software engineers, which, hmmm, not so common especially at large corporations)

Software engineers function better when they directly interface with the people they are serving. If an software engineer is on a team with the hydrolics people and wants to know how something works they only have to turn around.

If you’re in a ‘dedicated software team’ you escalate to your Business Architect, who escalates to the business team, whom contact the hydrolics department, whom ask an overworked engineer to respond to ‘another stupid question’ from the software team.

I kind of see where those things go wrong.

Interesting, so Airbus seems to be structured like Apple [1]

[1] https://daringfireball.net/linked/2016/11/28/yglesias-apple-...

I never heard Airbus claim "you're flying it wrong" when one of their types misbehaves.

Very simple, because they don’t have enough domain knowledge, and in addition, they will assume many things and blame others (the user) and still act superior towards people who actually use the product.

I’ve seen it so many times, so I’m not surprised by this at all