Explain to me like I’m 5…is software really that hard?

[llcsf]

R2 is shipping without pet mode, Rivian assistant, Gear Guard, hotspot, garage door opener, etc. That’s quite a long list and honestly very disappointing. I hope it just needs another week or two and it’ll be out shortly, but that leads to my topic question: is software really that hard? I don’t work in this field or anything close to it so I’m genuinely curious. These seem like pretty basic things from my ignorant point of view. What say you?

for rivian software people it especially the user interface part it seems to be very difficult….thye make mistake that make me think they are NOT trained software engineers but probably automotive hardware engineers. the mistakes I see are when i used to see many years aga when i came out of college with a software enginering degree and went to work with hardware engineers who thought they were programmers…you name major items that they probably decided to delay so they could get the R2 shipped….there are many minors user interface issues that will get you killed when driving the vehicle…example: try to find the time (they put in the far upper right in small font) while you are driving, same thning for temp). they could easily put these in the headsup screen….there plenty of other issues as well and they never fix them even after they are pointed out to them….so good luck on getting your R2 issed fixed very quickly

Sponsored

 

[SwampNut]

or is there a way to see if they can activate certain ones upon picking up the R2?

Absolutely not this. We all get the same feature set over time as they release updates.

This reminds me of the FM radio thread. Aside from all the bickering about the hardware costs, there's obviously a software and ongoing support cost, maybe more than the hardware. For pet mode, as others pointed out, failure is not an option. This is mission critical stuff, so while it's probably "easy" to tell the HVAC to stay running, making sure this can absolutely never fail is vastly more difficult.

Is software hard? Making "works OK most of the time" software is relatively easy. Making software that is 99% bug free is hard. Making software that absolutely can't fail ever...astronomically hard.

Source: Have led a variety of dev teams for many kinds of software, including mission critical public infrastructure.


Edit to add: Does the R2 have the "keep climate on" function that is separate from pet mode in the R1? This is less mission critical, which then means, obviously, you shouldn't trust it for actual pet safety.

 

[defcon888]

Reading these comments are informative. We are on the reservation list but will probably hold off until end of the year to upgrade. Not so much for these lack of software issues, but I think so they can work out the kinks on the overall vehicle.

We have had our R1T for over 3 years and it has been an amazing vehicle that has gone through some bumps and bruises but it has been solid.

We don't really care about the AUTONOMY feature because we don't want to put our lives in the hands of a $2.00 silicon chip. All we care about is the 3 "M's" (Maps, Music, Messaging).

 

[SwampNut]

We don't really care about the AUTONOMY feature because we don't want to put our lives in the hands of a $2.00 silicon chip.

Good news then, that's not how it is in any vehicle, so you can go ahead and use it.

 

[Time2Roll]

The independent functions are fairly simple. Integration with the other thousand functions gets exponentially more difficult as features are added.

I constantly see software upgrades that miss continuing functionality. Features and functions just disappear in name of progress. Not a Rivian specific issue, all software does this.

 

[Mos Eisley]

for rivian software people it especially the user interface part it seems to be very difficult….thye make mistake that make me think they are NOT trained software engineers but probably automotive hardware engineers.

Rivian has an estimated 1100 people on the software dev side of the company on two continents. Their head, Wassym Bensaid is a career software engineer, iot and systems dev including 7+ years in software at intel. Their staff is full of senior software developers with long careers on the software, not hardware side. Where your argument falls flat isthat if they were heavy on the automotive side, the things you argue for are GUI issues, clock location, heads-up... all hardware items that, if they were automotive engineers, they likely would have gone your direction IMO. I think the issue is the exact opposite, loads of software guys that are not focused on legacy hardware approaches.

https://www.linkedin.com/in/wassymbensaid/

 

[Husky]

R2 is shipping without pet mode, Rivian assistant, Gear Guard, hotspot, garage door opener, etc. That’s quite a long list and honestly very disappointing. I hope it just needs another week or two and it’ll be out shortly, but that leads to my topic question: is software really that hard? I don’t work in this field or anything close to it so I’m genuinely curious. These seem like pretty basic things from my ignorant point of view. What say you?

What could be hard about writing, integrating and testing thousands (more like millions) of lines of code? Yes, it's hard and time consuming - especially the verification phase, and especially when it needs to work perfectly so that there aren't thousands of ticked-off customers.

 

[GaryL]

Explain to me like I’m 5…

One of my favorite movie scenes
Margin Call

 

[Cycliste]

I used to be hard. Not anymore.

I recommend consulting a urologist for evaluation and treatment.

Don’t edit your post though, because those first two sentences made me pay attention, and well, laugh.

 

[Redmond Chad]

Is software hard? Making "works OK most of the time" software is relatively easy. Making software that is 99% bug free is hard. Making software that absolutely can't fail ever...astronomically hard.

Completely agreed. The first example that came to mind when I read this was the hard disk device driver for Microsoft Windows (called WIndows NT when I wrote it around 1990). I had it running fine in 2 or 3 days. But then I spent 6 months making sure that every path would recover gracefully if something bad happened. Which included bad sectors, more serious hardware failure, losing power, firmware that wasn't compliant to spec (that cost me a lot of time and made the driver have to be slower), mistakes in other layered drivers, etc. It didn't even have to be an error; just taking too long (which some hardware did) messed up our real-time SOPs so I had to have timers and a way to handle things if hardware or other software was slower than expected. I even wanted to handle someone opening the computer case and unplugging the hard drive while it was working (and yes, within a couple of months of Windows NT being released in 1993, someone forwarded me email from a customer that tried doing just that while copying an enormous file and was delighted to see that once he plugged it back in, it continued copying with no errors).

Code has to be very detailed, and every single thing you do can fail. Handling very rare failures is what makes software so complicated. Especially if you want to handle them in a graceful way that will give higher software layers and/or the end user an idea of what happened and how they should handle it.

 

[Zathras]

I used to be hard. Not anymore. AI can write the code in a fraction of the time required. What would take months is a few hours. I suspect RIVIAN is concerned about software privacy and it's a very valid concern. That said, I'm sure they will figure it out. So a year ago, it would take a team and months. Now, it's far simpler.

No, it's not easy, as Amazon found out after firing a bunch of software engineers and AWS almost melted down. All because Bezos doesn't get reality.

 

[SwampNut]

The first example that came to mind when I read this was the hard disk device driver for Microsoft Windows (called WIndows NT when I wrote it around 1990).

DUUUUuuuude...this needed a PTSD trigger warning. Sheesh. I know some of you did everything you could to make it failsafe, but...early versions still failed. I taught Windows NT admin 3.1 and 3.5 at the time.

In another thread, I mentioned that I've worked on 911 call routing software. It was SUPER easy to code. Trivial really. A day. It took weeks to find all the ways it could fail. Did the user dial it weird, and then hang up...failure mode. Did the user misconfigure their phone...failure mode.

 

[SwampNut]

Speaking of users and software testing, you usually can't pre-assess the creative ways users will seemingly on purpose seek to destroy your best-laid software plans.

A software tester walks into a bar.
Walks into a bar

Runs into a bar.
Crawls into a bar.
Dances into a bar.
Flies into a bar.
Jumps into a bar.
And orders:
a beer.
2 beers.
0 beers.
99999999 beers.
a lizard in a beer glass.
-1 beer.
"qwertyuiop" beers.
Testing complete, full pass.

A real customer walks into the bar and asks where the bathroom is.
The bar goes up in flames.

 

[StinkyPete]

As many people have said here (one way or another) that it really comes down to the edge cases and the quality assurance part (i.e., testing and defect resolution). The "what about this..." scenarios are MUCH more serious with a car's systems vs a video game (for example). The liability exposure for Rivian is huge for something like "Pet Mode" until it is fully dialed in.

Requirements/Business and Functional Rules - e.g., a what battery level is Pet Mode not able to be engaged due to the risk of the battery not being able to power the climate system, is there a limit for how long Pet Mode can be on (and if so... what happens if the limit is exceeded), etc...

 

[Husky]

Actually as a 20-year software developer AI definitely helps speed up things considerably. The real skill these days is breaking up tasks efficiently to small chunks so AI can do its thing. Testing is what really takes time though and everywhere I've been in, that was what kept things delayed so I assume it's the same in Rivian.

Exactly. As impressive as AI can be, it can still make crazy mistakes, and therefore needs careful verification and testing, which takes time.
Just a simple example; I asked ChatGPT to help me with a fairly simple woodworking jig for my table saw. I was having trouble visualizing what it described, so it made a sketch for me. It showed the workpiece being fed into the side of the table saw blade, towards the fence! At least in this case it's error was immediately obvious. Finding a mistake in thousands of lines of code? Not so much.

Sponsored