Earth Notes: Radbot: Origin Myth: 6
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 next time to find out more about Radbot's launch!
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. In one case involving a stack overflow (now if only someone could create a Web site for solving problems something similar ... oh wait ...) cost us a lot of data with a trivial software fix, and a lot of code rewriting in another. Which 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 saved later can be business-saving. And the increased confidence it can provide when refactoring, allowing one to be much bolder in code and functionality improvement, is fab also.
So being forward-looking for risks and deciding which are to be avoided and which just have to be rolled with, and minimising the pointless ones, is all part of the fun. Setbacks happen despite the best-laid plans of mice and men. How you then deal with them is key.