Earth Notes: Radbot Origin Myth 6 - Setbacks (2016)

Updated 2022-10-10.
"Setbacks" - Is it a bird, is it a plane? No, it is a radiator robot with AI! #webcomic
The Continuing Adventures of Radbot!
panel 1: should we stick with tried and true?
panel 2: cutting edge vs investors
panel 3: slow and steady wins the race
panel 4: but he took Radbot with him!
panel 5: logistical and money problems
panel 6: stuck in the astral plane
panel 7: we've run into another setback, amigos!

Radbot Origin Myth 6 "Setbacks" (Copyright © 2016) , editor .

Setbacks? We've heard of those! Maybe not getting stuck in the astral plane... Instead, horribly high failure hardware rates and serious software bugs. And physical and UI design faults, oh yes!

Oh, and the fact that people are weird and don't do what you expect them to do. I mean obviously the overhead camshaft should tuck under tab "B", right?

Those require replacements in the field, or loss of trial data. Or other bad things. One just has to grin and bear IoT...

Confused? You will be!

Tune in to find out more about Radbot's launch!

Back Story

The pain of safe code development for embedded systems, ie 'smart' hardware (Testing times: Between some IoT code and a hard place) is very real:

In smaller companies and startups the pain can be intense. I remember a job before going to university where I sweated for a week over hardware that stopped working just before a critical demo in the US. It was for a robot toy for a couple of the world's largest purveyors, and no one would have died... except for my employer. We slept under the desks (my landlady thought I must be out doing drugs and summoned scary relatives to hound me) and we tore out our hair, some of which may even have turned grey.

It all turned out to be down to one tiny misplaced wire on our development electronics board, discovered at the 11th hour when rechecking "everything".

We did the demo, the project continued, and my employer lived.

Radbot has suffered similar hardware and software bugs. One case involved a stack overflow. (If only someone could create a Web site for solving problems something similar ... oh wait ...) It lost us a lot of data but had a trivial software fix. Then a very long drawn out code rewrite that took months to nail. That is why I am strongly in favour of extensive (unit and other) tests and CI (Continuous Integration), just as I am for 'bigger' software. Never mind the techie grumbling; the pain can otherwise prove fatal. The increased confidence those tests can provide when refactoring allow much bolder code and functionality improvement. Also fab.

Actively assess risks coming down the pipe. Decide which are to be avoided and which just have to be rolled with. Avoid the pointless ones. It's all part of the fun. Setbacks happen despite the best-laid plans of mice and men. How you then deal with them is key.