Says a lot about their internal organisation structure for something like this to happen. Intern is the only tolerable excuse here, but even still why would you put a newbie in a position where they could brick thousands of vehicles with a slip of the finger?
I’d expect a tech company like Rivian who happens to sell a vehicle to know better than this 🤦♂️
wrong build with the wrong security certificates was sent out
Isn’t standard practice to validate signed code first before installing it? Hope the next update allows the car’s computer system to check the firmware signature before doing what I assume is an automatic installation…
I don’t follow your line about an intern. I don’t see it in the article and even if it were the case, an unqualified person being able to do this is on the seniors/leads. Throwing the intern under the bus is what scummy companies do to shift blame - see solar winds , where (spoiler) this strategy doesn’t seem to be working out
It’s more incompetent to allow an intern to fuck up production than it is to have normal developers make mistakes. It shows a complete lack of controls and care.
Anyone who builds software that runs on actual hardware should know that you NEVER deploy builds that haven’t been fully exercised on actual hardware.
This tells me that their software QC process is non-existent at best and actually malignant at worst.
If their software is supposed to be their defining feature this is the equivalent of McDonald’s “accidentally” shipping frozen discs of literal shit instead of burger patties to franchises who then serve them to customers without question.
If their company dies because of this (it fucking should imo) they 100% deserve it for the countless unknown dangers they’ve exposed their customers to. It’s not this particular thing, bricking the infotainment system, it’s the demonstration that they have no or bad process.
Interns do but should not get the level of write access that makes a durable change impacting all customers. Deadlock a server or even wipe SQL tables, this is an outage. Break a customer’s configuration, send the wrong client’s paperwork, again small scale problem you can deal with. Interns don’t change company policy.
I think it’s a more foundational architecture question: why do you push builds to all customers at once without gating it by SOMETHING that positively confirms the exact OTA update package has been validated? The absolute simplest thing I can think of is pushing to 1 random car and waiting for the post-install self tests to pass before pushing to everyone else. Maybe there’s actually no release automation?? But then you make it safe a different way. It’s just defensive coding practice, I’m not even a CS degree but learned on the job something always breaks so you generally account for the expectation that everything will fail by making a fail-safe just so the failure is not spectacular. Nothing fancy, just enough mitigation to keep the fuck up from eating into your weekend if it happens on a Friday.
Says a lot about their internal organisation structure for something like this to happen. Intern is the only tolerable excuse here, but even still why would you put a newbie in a position where they could brick thousands of vehicles with a slip of the finger?
I’d expect a tech company like Rivian who happens to sell a vehicle to know better than this 🤦♂️
Isn’t standard practice to validate signed code first before installing it? Hope the next update allows the car’s computer system to check the firmware signature before doing what I assume is an automatic installation…
Ouch
I don’t follow your line about an intern. I don’t see it in the article and even if it were the case, an unqualified person being able to do this is on the seniors/leads. Throwing the intern under the bus is what scummy companies do to shift blame - see solar winds , where (spoiler) this strategy doesn’t seem to be working out
It’s more incompetent to allow an intern to fuck up production than it is to have normal developers make mistakes. It shows a complete lack of controls and care.
https://www.rivianownersforum.com/threads/rear-ended-rivian-gets-42-000-repair-bill.5445/
Ouch indeed.
Anyone who builds software that runs on actual hardware should know that you NEVER deploy builds that haven’t been fully exercised on actual hardware.
This tells me that their software QC process is non-existent at best and actually malignant at worst.
If their software is supposed to be their defining feature this is the equivalent of McDonald’s “accidentally” shipping frozen discs of literal shit instead of burger patties to franchises who then serve them to customers without question.
If their company dies because of this (it fucking should imo) they 100% deserve it for the countless unknown dangers they’ve exposed their customers to. It’s not this particular thing, bricking the infotainment system, it’s the demonstration that they have no or bad process.
Interns do but should not get the level of write access that makes a durable change impacting all customers. Deadlock a server or even wipe SQL tables, this is an outage. Break a customer’s configuration, send the wrong client’s paperwork, again small scale problem you can deal with. Interns don’t change company policy.
I think it’s a more foundational architecture question: why do you push builds to all customers at once without gating it by SOMETHING that positively confirms the exact OTA update package has been validated? The absolute simplest thing I can think of is pushing to 1 random car and waiting for the post-install self tests to pass before pushing to everyone else. Maybe there’s actually no release automation?? But then you make it safe a different way. It’s just defensive coding practice, I’m not even a CS degree but learned on the job something always breaks so you generally account for the expectation that everything will fail by making a fail-safe just so the failure is not spectacular. Nothing fancy, just enough mitigation to keep the fuck up from eating into your weekend if it happens on a Friday.