That's certainly true of the software in my 2017 Prius Prime (which was mostly written by Denso for Toyota - and it does at least display a proper GPL notice, so there's that to say for it, but not much else) However Toyota does finally seem to be making some progress on the software front with the AGL rollout[1] which will also at last bring Android Auto and Carplay support (just not to all of us sad owners of older models).

1: https://www.engadget.com/2017/05/31/toyota-automotive-grade-...

Hardware can usually be spec'ed reasonably accurately from the start. "The Toyota Way" can incrementally optimize building against a specification, from the bottom up, starting with smaller details.

Software however is all but impossible to spec from the beginning, or perhaps ever at all... so with only working with the smaller details, the larger picture is lost. At any time, any team, is instructed to stop a problem and immediately fix it, it's band-aids on top of band-aids.

Having multiple teams working on overlapping projects, with little communication leads to the spaghetti code that was mentioned.

You can spec hardware, but when the company goes behind the engineering teams back and lies and saves a few pennies per car by not putting error-correcting RAM on the things they say they will... you're kind of left hanging on that. And that's how Toyota works or at least worked when building the Corolla (just one of the best selling cars ever).

Much of the code being dealt with by Toyota (at least that subject to the lawsuit and so made available for analysis) was embedded code which is a bit more amenable to very deliberate design, testing, and verification. NASA, for instance, has a long history of producing extremely reliable software, even proving the software correct at times. Would any private corporation in the world ever resort to following such a practice? Never. It would quadruple their software spending and, maybe worse, they would have to listen to their engineers. When the business wants to ship a project, if the engineer says 'its not ready yet', if its a bridge and they go ahead someone in a suit goes to prison. If it involves software, everyone goes home happy except the dead customers.

>>> Software however is all but impossible to spec from the beginning, or perhaps ever at all... so with only working with the smaller details, the larger picture is lost. At any time, any team, is instructed to stop a problem and immediately fix it, it's band-aids on top of band-aids.

Embedded software can be spec most of the time and it should be.

The discrepancy in quality probably indicates a deeper deficit of maturity across the software engineering discipline in general.

My informed opinion is that Toyota's software is robust but crappy.

The software you would use to configure the parameters in the car (e.g sensitivity of headlights turning on, whether or not it'll chime when you're not wearing your seatbelt) hasn't even been ported to 64 bits yet. It seems to have been written by one of their O.E.Ms (Denso) and it seems like the cars have used many of the same design patterns since the 90s.

Look no further than the infotainment system, it's always a generation behind other automakers and we all know that most automakers don't set the high bar of consumer technology.