Tesla, Auto-Pilot, and software development

Reading a pretty cool and short (text)book (yawn), called “A gentle introduction to the art of object-oriented programming in Java. (yes, a truly exciting two volume set)

Uses as an example, the programming of a robot.

Reading this book, and also reading the recent news posted by my former colleague Charles Rader, about the first fatal accident with Tesla’s autonomous self-driving car, makes me realize:

I truly know crap about software development.

Writing a program to handle screen or web transactions is so much different (read: way, way easier), than writing a complex set of software routines that simultaneously interfaces with dozens, if not hundreds of real-time sensors.

Yes, I know, not one person wrote all that software, AND, not all of it was written “all at the same time”.

I guess, like I told my high school best friend (Tom Kuenzli – where are you now, my friend??) while we were in college, that it’s like designing and then building a house. You break it down, into modules, then sub-modules, and, then, even to the various pieces of lumber needed, and, voila’, you’ve created a blueprint (the “design”), etc.


So, the car’s (or robot’s) software was designed, and developed, and, tested, over a period of years, if not over the past dozen (or more) years [software and even hardware, is always continuously being enhanced – added upon]. They first did one module, then another, then a third, then the three thousandth module, and over time, meshed all of them together, making sure all these modules and their interfaces spoke to each other like they should, without error. Making darn sure, all the modules were capable of handling ALL inputs, whether expected, or unexpected.

(in the case of the Tesla automobile, apparently, the various sensors might not have “read” (or “noticed”) a white sided truck against a white horizon background in enough time in order to slow or brake a vehicle going at a pretty fast clip. Personally, I don’t think it was a software issue (and, I could be wrong), but a train engineer cannot stop a train on a dime – software (sometimes) (and the associated hardware, like brakes) at this point in time, may not be able to stop a car on a dime – this is why the people at Tesla caution their car owners (AND also require their explicit acknowledgment, each and every time, the auto-pilot system is engaged) to still keep your eyes on the road AND hands on the wheel at all times.)


Ok, sorry, back to software development.

I have enjoyed and truly loved my career in I.T., but I really missed out by not branching out into embedded (computer) systems.

It would be so way cooler when answering Lailah about what kind of work I did (when she’s 13, and I’m <much, much older than I am now>, saying, “see that robot over there? I designed and wrote the software for his fingers to pick up that egg without breaking it”, instead of saying, “Honey…I created billing reports for the payroll system at NCR”.

Just sayin’

(she then asks, “Oh, I don’t think I’ve ever heard of NCR, what did they do?” They used to make cash registers, Honey. “Oh! <long, long pause>…what’s a cash register, GranPa?”)

(I guess I could put in my real life example: “I worked at Burroughs, Sweetheart…they made adding machines”. Oh! …GranPaBrian… “Yes, honey?” …What’s an adding machine?). 🙄😉🤓

📚📖
⌨💻🖥
🤖🤖🤖🤖
🙄😉🤓

(Love you guys, love those of you in the audience who enjoy reading my blog posts. You’re the best.)

Ok, back to “A gentle intro to the art of (OO) programming…”

If you don’t hear from me by tomorrow morning, the robots (programmed in Java) have taken over beautiful downtown Apple Valley…