AbsoluteUnit
Kraftkurve King
I don't think that's how it works.This is not true.
Always by products for what they are. Not what they could be. Software can be harder than software.
A business might launch a software but then lose the staff that developed it or don't want to repay the licence fee or consultancy for development software. This is especially true if the software stack includes different service providers or tools.
With cars, they usually fix issues by addressing them in the succeeding model that they want you to buy.
If its a third-party developed drivetrain logic, then you don't just pay a license fee once for the software and call it a day. You will enter in a software support agreement to maintain that software in case of future software issues or defects. Otherwise you'd be completely f#cked if your provider made a mistake. There are contingencies built in for this exact reason. And I imagine there is heavy legislature involved given that problems can be fatal when vehicles are concerned.
Regarding the point about usage of multiple service providers. Well, when you're doing a software deployment there will be a considerable amount of development time and resources placed on integration and integration testing. Especially if its microservices-based. We're talking about drivetrain logic here, so I'm not entirely sure microservices are relevant. But even if we do have different logic being handled by different companies, once again there will likely be an internal Mercedes team working on integration between different pieces of software. And of course there will be a customer support agreement covering change management and defects.
With regards to loss of personnel. Well codebases will exist irrespective of who authored it. The code isn't just lost to the aether, its stored centrally. Perhaps using Github or Gitlab or whatever else. Software engineers come and go all the time. Perhaps there will be time needed to learn how the code works and tweak it, but it is possible. We're not dealing with arcane knowledge here, just programming languages.
And you are right about issues being fixed in succeeding models. However, that is only true historically. And even then its not entirely true. Models have had recalls due to defects, software issues and whatnot plenty of times. The issue wasn't just allowed to remain until the next model. The recalled cars are well... recalled, updated (can be a hardware or indeed a software fix) and then returned to the customers that bought them. There are also in-cycle adjustments. If say for example an engine has faulty fuel injectors (say like the N53 and N54), firstly there will be either be a recall to fix them if the issue is very widespread. Or the manufacturer will update their warranty and allow owners to have those issues fixed free of charge, under warranty. And then they won't just continue to sell a car with frequently failing injectors, they'll change the part to a more reliable part, so that they don't have to keep fixing cars for free for the full 10 year life-cycle of a car. There is an entire element of product lifecycle management that covers this. Not just for automotive, but all kinds of manufacturing. Software is an element of product lifecycle management.
More broadly, nowadays more and more manufacturers are moving towards centralised computers for their in-car logic (think BMW's "heart of joy") and general connectedness of modern vehicles, it would not surprise me if there are over-the-air updates possible for things like drivetrain logic. Or they could do a stealth update before/during the facelift.
Its complicated sure, but this is not outside the realms of possibility. These car companies are as much software companies and system integrators as much they are vehicle manufacturers.