Well, hardware is a different world from software. I’ll bet that Tesla doesn’t do “sight unseen” updates. They probably wouldn’t be allowed to.
They likely have huge batteries of tests that the software needs to pass (CI), but the actual release build and “sign-off” involves a human.
Who will get their ass chewed off, if the update borks.
But everything before that point, is 1000% better and more agile than most hardware companies.
I’ll bet SpaceX has a lot more meatware in their process.
I always liked CI, as a basic infrastructure, for my team. I very much believe in early integration testing[0], but automated testing can be a trap. It should not be the only testing, for firmware.
If you push a bad release to a Web server, you have one point of failure, but also, one point of recovery.
If you push out a bad firmware release, you have a million $10K bricks. You may also have fires, explosions, and crashes.
Although I often had real disagreements with the hardware folks, I am entirely sympathetic to their priorities.
The main issue, was that they considered software developers to be “cowboys,” and judging from the general quality level of even enterprise software, I can understand their bias.
However, I am not a “cowboy.” I am absolutely anal about Quality, and I’m regularly attacked as being “too uptight,” by software developers.
Software is a different animal from hardware, and needs to be done differently. Quality, however, should not suffer.
As a standalone developer, I’ve learned to eliminate “concrete galoshes”[1], and CI tends to be that, but only in my case. What works for me, may not work for others. Just as importantly, what works for others, may not work for me.
I’ve spent the last few years, refining a personal process for my software development. It works great. You can see for yourself. Most of my work is open-source, or source-available[2].
For the people who are downvoting me, you do all realise that I'm not comparing a pure-software website to some embedded IoT thing, right?
Most of my examples are hardware with software as "necessary evil" vs hardware with software "being taken seriously."
Apple TV is a hardware appliance that takes the software seriously.
My Samsung "flagship" TV is a hardware appliance that does not.
They both get updates. One gets frequent updates that makes the product noticeably better. The other gets infrequent updates that have made it worse.
Cars from most manufacturers are hardware with trash software.
Tesla sell the cars, but unlike their competition their cars are regularly updated with new software. They have weekly(fortnightly?) updates rolled out to their for their beta testers! Not exactly daily CI/CD, but compare this to Toyota. They literally never release updates for most models, ever. And it's not like their 1.0 release is perfect! Mine has a bunch of small bugs and irritations that they should have patched... but never ever will.
It's not a question of "alternate process" or a "different workflow". They have no process! Their release strategy is "don't"!
Apple is about to release a complete car software + hardware suite. So not something you plug in, but the entire "avionics" as it were will come as a OEM part from Apple instead of the car manufacturer.
They're going to wipe the floor with their competition. The screens and software from GM, Ford, Audi, BMW have nowhere near the quality, commitment to updates, backporting of new features, etc, etc...
I will literally stand in line outside of the dealer to get a new car that has this style of Apple-made hardware+software instead of a lump of metal with paint on it and fabric on the inside.
Because I know it will get updates, and that those updates won't make things worse.
As a fellow embedded dev, I think that any system where you run a regular, meaningful risk of bricking with updates is a badly designed system. Other than that, no disagreement. CI is a cheap, fast first step in validation. It's not the stopping point.
Well, I don't do embedded anymore. I enjoyed it, but it can be nerve-wracking.
I write end-user application code, for Apple devices, in Swift. I really enjoy that.
I also do some backend stuff (in PHP). It's not my forte, and I like to avoid it, if possible, but I'm highly skeptical of a lot of backend stuff, these days, and like to know who I'm letting in the back door.
I'd like to do some Bluetooth stuff. I've written a bunch of BLE stuff (even given a class in it[0]), but I haven't found a venue that gives me an excuse (the Meshtastic stuff looks like it might be a good bet, though).
They likely have huge batteries of tests that the software needs to pass (CI), but the actual release build and “sign-off” involves a human.
Who will get their ass chewed off, if the update borks.
But everything before that point, is 1000% better and more agile than most hardware companies.
I’ll bet SpaceX has a lot more meatware in their process.
I always liked CI, as a basic infrastructure, for my team. I very much believe in early integration testing[0], but automated testing can be a trap. It should not be the only testing, for firmware.
If you push a bad release to a Web server, you have one point of failure, but also, one point of recovery.
If you push out a bad firmware release, you have a million $10K bricks. You may also have fires, explosions, and crashes.
Although I often had real disagreements with the hardware folks, I am entirely sympathetic to their priorities.
The main issue, was that they considered software developers to be “cowboys,” and judging from the general quality level of even enterprise software, I can understand their bias.
However, I am not a “cowboy.” I am absolutely anal about Quality, and I’m regularly attacked as being “too uptight,” by software developers.
Software is a different animal from hardware, and needs to be done differently. Quality, however, should not suffer.
As a standalone developer, I’ve learned to eliminate “concrete galoshes”[1], and CI tends to be that, but only in my case. What works for me, may not work for others. Just as importantly, what works for others, may not work for me.
I’ve spent the last few years, refining a personal process for my software development. It works great. You can see for yourself. Most of my work is open-source, or source-available[2].
[0] https://littlegreenviper.com/miscellany/testing-harness-vs-u...
[1] https://littlegreenviper.com/miscellany/concrete-galoshes/
[2] https://github.com/ChrisMarshallNY#browse-away