The is the first in a series of “Single Point of Failure” discussions I’ll be posting.
I am a “Two is One, and One is None” sort of person. I’m more comfortable with decent levels of backup and redundancy than I am in winging things with a one-off kludge.
Most ham radio shacks have a computer where we run loggers, control software, other controls, utilities, DX clusters, digital mode software, voice/code keyers, audio processing, and all the other software parts of our ham radio toolbox.
Over time we tend to build our operations around how all the software parts work for us.
But do we step by step create dependencies that we might not give enough thought to, and further fail to recognize that we’ve accepted “Single Point of Failure” situations as our new status quo?
These software “Single Point of Failure” issues maybe as simple as will the software we’re depending on be maintained, updated and supported? Or they maybe less obvious like “what happens if the sole developer drops out or gets ill?”
Or what happens if they move their product in another direction, or make a gross technical mistake, or simply talk the talk while not walking the walk?
Recently a tale was shared with me about a developer who got passive/aggressive with his own product’s users when they figured out a workaround to what he claimed was a serious problem – and got himself so worked up that he purposely disabled the workaround because it ticked him off to be wrong. As far as I know this developer works alone, and has no understudy or heir-apparent, nor would it seem any wise counsel.
So what happens to your shack if he loses it, or if he isn’t able to do his job, or when he wants to retire (provided he hasn’t declared it “too much” along the way)?
How long can you expect the package to be usable in a world of every updating operating systems, drivers and radios?
Should you have an alternative program ready to implement?
Do you have your Plan-B option ready at all times, or something to deal with only if you have to?
In many cases you have to bluntly evaluate if there are any viable alternatives.
When it comes to the software in our radios we are often stuck without options. Example, I have some modern loaded EPROMs for my Heath-9000, as the originals are noted to basically lose their program load, leaving the radio software-less. I have archived away the loadable software for some of my other legacy radios.
I’ve had to evaluate and am comfortable with my FlexRadio Flex-6000s given the size FlexRadio has grown to, the number of engineers working on their products, and the stability of existing versions to “just run” when I need them, versions which I’ve archived away for a rainy day.
But I’m a bit more hesitant to implement software from a less reliable or even an unknown source unless I have at least one other ready alternative in the wings.
Some package types that particularly are worrisome are complex “Swiss army knife” all-in-one packages, small speciality programs, and overseas programs where few in the community know the author.
Very complex programs tend to bloat until they overwhelm the available support resources of the developer. I finished coding a project another grad student abandoned as it simple got away from them, and they walked to first better paying less frustrating job. I succeeded by breaking the project into manageable chunks and offloading one tricky bit into less common but available hardware. I’m pretty certain the project ran for a number of years past my involvement without a hitch, but then I did hear that a successor grad student got frustrated at the complexity and left the project again hanging in the breeze and it folded.
Small specialty programs are often “instant abandonware” as the developer usually has bigger fish to fry. Again dating myself when challenged to expedite bulk file transfers between two mainframe architectures I wrote a series of transition utilities to automate the process. Memory says they were done in either Turbo-Pascal or Turbo-C on a Columbia-PC in stone cottage in the English Pennines mountains. After a couple of weeks use they were set aside until I received an email (remember FidoNet?) a couple years later asking if I could tweak them as they wanted to move another archive. I couldn’t do the work as I was on assignment in a Germany factory, but I was able to given them the source code to do away with what was quickly a nuisance project. Problem solved and I avoided getting bogged down in code work when I had several entire factories to run.
In my current professional role I our firm has a set of floppies of a very nicely done program that as I understand it was developed by someone from overseas who had a booth at a trade show but for unknown reasons abandoned his very workable and clever program in a couple years. No one knows if he died, lost rights in a divorce, became a monk, or if he was just bored. All we knew is his stuff stopped working along the way as MS-DOS gave way to Windows. I was tasked to first try to find the developer and secondly evaluate if the code could be updated without him if he couldn’t be found. Seems that he had emigrated and the code would need a rewrite to be viable, and more importantly sound affordable alternatives were found.
Now I could repeat each of these scenarios with ham radio programs I purchased as the subject. Our hobby has a fair bit of abandonware and programs being ignored by their developers. I’d venture that a third of the ham programs I’ve tried have fallen apart within five years of my purchase. I’m avoiding naming names as for the most part I did get some useful life out of the programs, and it only became frustrating when I had to replace them with something else.
Again without naming names I do believe there are few popular ham programs out there that are at risk of becoming abandonware at nearly any moment. Will they make it through the next Windows update, or will they work with the latest monitor or next radio, or will the single developer lose interest or fade away?
Greatly tempering my approach is if the software is open source, freeware or donationware, or if the developer is part of a team or hs family involved.
YMMV but lacking mitigating factors I am striving to have a substitute on the ready, or if possible to just avoid the risk all told.