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

[SwampNut]

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.

LOL, ChatGPT is trash. I've found that SuperGrok and Claude Pro give me very good shop stuff, with Claude being great at OpenSCAD code for 3D printed parts, tools, and shop fixtures.

Edit to add: Claude's long term memory is great, and it has often said it recommends specific things "for someone like you with a woodworking shop" or similar.

Sponsored

 

[Mos Eisley]

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 om a customer that tried doing just that while coping 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.

Great background -add to this the matrix of making it work across multiple 3rd party user interfaces like not only making the car's software support android and car play, but support it across multiple versions of those OS' on multiple hardware devices. Easy to see why Rivian would want to be 100% vertically integrated in terms of the tech stack and user GUI.

My wife is an audiologist. Over the past twenty years it's gone from selecting a simple hardware device and popping it into an ear to fielding daily calls regarding problems that arise because the aid is now software dependent and every time the customer's phone updates, the customer gets lost, confused... the doctor now has to be IT support.

I appreciate the responses here from experience coders/engineers.

 

[Zathras]

Writing software is not any more difficult than writing a paragraph. Tying your shoe is also very easy. But, writing a paragraph of instructions on how to tie your shoes - that is not so easy.

Clearly you don't write software of any complexity. I took my first class in Fortran in 1973. And I've messed with programming ever since off and on. Anyone who thinks it's easy is what the psych boys call Dunning-Kreuger.

 

[DCFC]

Remember that R1 launched with only a fraction of the functionality that it has now. Camp mode, dog mode, 360 camera, car wash mode, gear guard, etc.... these are just a tiny fraction of features added over the air after the vehicle was launched.

 

[Zathras]

LOL, ChatGPT is trash. I've found that SuperGrok and Claude Pro give me very good shop stuff, with Claude being great at OpenSCAD code for 3D printed parts, tools, and shop fixtures.

Edit to add: Claude's long term memory is great, and it has often said it recommends specific things "for someone like you with a woodworking shop" or similar.

Hilarious to compare a chatbot making 3D parts for a wood shop to creating vehicle software, which has to meet a bit higher specifications than "can it make a great 3D object?"

 

[SwampNut]

Hilarious to compare a chatbot making 3D parts for a wood shop to creating vehicle software, which has to meet a bit higher specifications than "can it make a great 3D object?"

That would be hilarious if anyone did that. You misunderstand a lot of posts here, as you did above with GMAR's post. Try reading more slowly.

 

[Zathras]

That would be hilarious if anyone did that. You misunderstand a lot of posts here, as you did above with GMAR's post. Try reading more slowly.

Sure, my sarcasm might have been a bit off target, but a chatbot making patterns for 3D parts? Try making software that could design 3D parts, now that would be a challenge.

 

[CrazyOne]

It takes time and money. If you rush it, you end up with many examples like the countless failed car startups.

Question from a person who has never owned anything EV and is not computer savvy (sorry, don't bash me I'm trying )! Does this mean these features will eventually be there, or is there a way to see if they can activate certain ones upon picking up the R2?

If you are talking about things like pet mode that already exist on R1 AND are promised, they will almost certainly happen. If you are talking about self driving features, I want to day that G1 owners got similar promises and what we got is not better than a 2017 Mazda with standard Mobileye system.

 

[GMAR]

Clearly you don't write software of any complexity. I took my first class in Fortran in 1973. And I've messed with programming ever since off and on. Anyone who thinks it's easy is what the psych boys call Dunning-Kreuger.

On the contrary - my entire career was designing and implementing software. Perhaps the point in the analogy I was trying to make was not clear. It is easy to write a program to turn a fan on and off. It is difficult to write a program that turns a fan on/off automatically based on the temperature, what is in view of a camera, time of day or according to a schedule taking into account daylight savings, etc. My point is coding in a language is not too difficult but designing and creating an application based on multiple conditions, scenarios and variables is exceedingly difficult. And one that is tied to safety (like for a pet) is extremely difficult as it must never fail.

 

[Zathras]

On the contrary - my entire career was designing and implementing software. Perhaps the point in the analogy I was trying to make was not clear. It is easy to write a program to turn a fan on and off. It is difficult to write a program that turns a fan on/off automatically based on the temperature, what is in view of a camera, time of day or according to a schedule taking into account daylight savings, etc. My point is coding in a language is not too difficult but designing and creating an application based on multiple conditions, scenarios and variables is exceedingly difficult. And one that is tied to safety (like for a pet) is extremely difficult as it must never fail.

Okay, I see your point. That is very true.

 

[SwampNut]

but a chatbot making patterns for 3D parts?

I didn't do that.

Try making software that could design 3D parts, now that would be a challenge.

That's what I said it was doing.

Comprehension 101.

Okay, I see your point. That is very true.

Glad to see that, which was my point about misunderstanding.

 

[andersonjanette]

they’ll come in a future update
Yep pet mode and assistant was what I was curious about. Happy to wait on a self-driving feature!

Thanks!

It takes time and money. If you rush it, you end up with many examples like the countless failed car startups.
If you are talking about things like pet mode that already exist on R1 AND are promised, they will almost certainly happen. If you are talking about self driving features, I want to day that G1 owners got similar promises and what we got is not better than a 2017 Mazda with standard Mobileye system.

 

[VandalSibs]

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.

Reminds me of a ditty I read about once (paraphrased)...

"99 bugs in the code,
99 bugs in the code,
Take one down,
Patch it around,
127 bugs in the code"

 

[SwampNut]

Reminds me of a ditty I read about once (paraphrased)...

"99 bugs in the code,
99 bugs in the code,
Take one down,
Patch it around,
127 bugs in the code"

And then, regressive bugs. Things you -ahem- "fixed" and come back a year later. I may have that in the Rivian right now.

How many software devs does it take to change a light bulb?

Fuck that, it's a hardware problem.

 

[Redmond Chad]

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.

Funny. Yes, despite many coders working hard to write great software, the software was not great. Which leads me to another important point about the difficulty of releasing good software: the people writing the software often don't get to pick the delivery date. Or the feature set, which often has things added late in the game..."just slip this in without changing the delivery date".

In the Win NT 3.51 example, NT's native presentation layer was abandoned for an interface compatible with x86-real-mode-Windows well into the game. I completely agree with the business reasons for making the change, but developers weren't even asked about how it would affect the schedule before promises were made to customers. It was an enormously complicated change, and caused a lot of problems, but there was still all that pressure to get it out the door...

This was not the only example. On every product it seemed executives made promises to customers and then told developers to make it happen without even bothering to ask if it was possible. So we'd work extremely hard just to deliver something we weren't proud of. It's most of the reason why I left the company. I am happy to see Rivian waiting until the missing features are ready rather than releasing them and just hoping for the best.

Sponsored