> Automotive engineering is antediluvian wrt process compared to software engineering.

I couldn't disagree more strongly.

> Our design processes are far in advance of the automotive industry. Continuous design is normal practice. It's only the most careful (or most backward) shops that'll take months to update a design.

I'd say the latest trends in software engineering processes are actually adaptations of what has been practiced in the automotive sector (and other manufacturing sectors) for a long time, but outside of regulated industries, practiced with far less rigor. I don't think the claim that development processes in software are "more advanced" holds water (what does that even mean?).

It's impractical to practice continuous design on a physical product like a car so I think that's a poor point, but kaizen (which I will argue serves an analogous role) is certainly used throughout manufacturing and has origins in the TPS.

> The automotive industry, by comparison, regularly takes years to update a design even by a minor version. The best shops at this i.e. the F1 race teams can fix bugs in days, minor releases in months and, if this season is anything to go by, struggle horribly with major version upgrades.

Ignoring regulatory and documentation concerns, part of the reason it takes years to update a design is that the costs associated with producing a physical product are completely different from a pure software product. It's more cost effective to do good design work and heavy V&V of your design before you order tooling, rather than trying to modify your tooling (if it's even possible) after an error is discovered.

Exactly! The auto industry works like it does because it HAS too, not because it is better. Software design is much better and more advanced, because our industry allows us to choose better practices.

You know you have a programmer's mindset when you think flailing around is a "better practice" than actually designing your product. :-p

I don't think we're on the same page.

> Software design is much better and more advanced, because our industry allows us to choose better practices.

I don't know what "much better and more advanced" is specifically referring to, but in the general sense, I see SDLC processes used in the stereotypical tech startup to be cargo cult appropriation from other more mature industries.

"better"

What does that word even mean?

Number of errors fixed. Software engineers fix more errors in their designs, ergo, they must be using better practices! /s

Human safety adds massive overhead to any mechanical engineering project. I worked in aerospace. In probably 1-2 days, we could conceivably change a part drawing, send it to the shop, then have it start being manufactured en masse. Why don't we do that? Because the part drawing must be reviewed by the analysis group first. Altering part geometry can change load paths. We might have enlarged something to strengthen it, but now it requires a larger hole elsewhere. It can take days to months to anaylze the part change. We do manual calculations, physical simulations, and physical testing. Each of those is still not at the point where we could pass it to a strong AI, they're all part art and part science that require an engineer's manual, informed decisions. Correcting experimental data, deriving new calculations, even just making diagrams and describing all of this along the way takes time. We must document everything. We might have to design and build a test fixture from scratch (airplane wing test fixtures aren't exactly off the shelf). Experiments get run wrong, they set the wrong loads, a tech installed a sensor 1 inch off, meaning we have to throw out a month's worth of data. Humans make mistakes. We do our best to catch them. Only after all this can we get regulatory approval (FAA in our case) and start pushing it to production. Honestly the attitude that software eng is "light years ahead" is infuriating, mechanical engineering is rife with time consuming checks and triple checks so that people do not die.

Have them ride a plane designed using an Agile process.

When my pilot announced last night we were doing an autopilot landing, that's exactly what I was thinking.

Why should this discussion be limited to out and out software companies. Think NASA. Think New Horizons. Think about the nuclear reactors and what would happen to them when a sensor gives a wrong reading for reaching critical level. These are some pretty serious use-cases where Software Engineering processes are highly developed and rigourous.

The computing systems used in a car itself (what do you think triggers the airbag on an accident?) can be trusted because of maturity in Software Engineering.

Startups don't choose to follow these methods to keep costs low and stay lean. I say that in the broadest sense, because a banking startup will be different from your average SaaS startup.

I agree - I think the reason they took it aside and investigated the root cause was that they couldn't afford to produce very many defective parts at £7,000 apiece, whereas in software each defective instance is (nearly) free.

That said, I've worked in teams who were developing software that would be boxed, shipped, and installed on millions of remote devices, and I've worked on teams whose main focus was "keep the service running at all costs". The former definitely emphasized root cause analysis, because screw-ups were insanely expensive and difficult to fix once they were shipped. The latter - not so much.

People who write software shouldn't brag about making billions of perfect copies, or being able to make changes in hours, because that is just an aspect of their field which is inherently easier than automotive engineering. It isn't any process improvement that has made that possible, and automotive engineering can't simply copy the software engineering process to reap the same benefits.

Working in an easier field doesn't mean your field is more mature. Especially when there is such dramatic uncertainty in the schedule and the output is so flaky.

Yeah, call me when you software crashes less than a car (due to design or manufacturing defect).

As our world intersect with more and more lives on the lines like with self-driving cars, we need to understand how these things interact in terms of development cycles and process.

We (as software developers) don't need to adopt their models and processes, but we need to figure out how to work with them to ensure higher reliability across the board.

The alternative will be formal certifications/licensing pushed on us by legislators who don't know how to send an email and think mathematics is a weapon to be regulated.

As a counterpoint, I'm a software tester on a project right now that has:

* Several of the component programs read from multiple config files

* Manual registry settings

* Config files have True/False, On/Off, and Yes/No settings.

* The version is reported to a db on program run, but the version is read from an xml file, not the program.

It is true that a new car program can take 5 years or more to roll out, but at least it actually happens. This system has been in use for at least 15 years, and it just keeps getting kludged.