Skip to main content

On aging (software)

I’m looking at an old (early 20th century) hand-crank record player that was handed down to me from my great-grandmother. It’s a simple wooden box with a spring & flywheel mechanism that spins the turntable at a somewhat constant speed, a metal needle that rides in the grooves of a record disk and transmits the vibrations onto a small metal drum, and a big metal horn that focuses the sound from the drum and directs it out into the room. The power source is a human winding a spring. The sound and amplification are purely mechanical.

It’s simple. If it breaks you can take it apart, look at what’s inside, and with just a bit of tinkering you’ll probably get it to work again. If it somehow survives a few thousand years, the people from that era will look at it, figure out what is is supposed to do and with a bit of tinkering it’ll be made to work again. If one were to draw the mechanicals out on archival paper, a person from the future would be able to create a functioning replica using only late 19th/early 20th century technology.

The modern equivalent? Instead of wood and metal that with maintenance and preservation can be made to last centuries or can be recreated from scratch with a bit of work, we have disposable silicon & proprietary software – with no realistic means of preserving or maintaining over a long period of time.

For me, the non-maintainability and short life of software-centric devices affects how I view long term purchases. I shun software dependency (and internet connectivity) on devices that I expect to last more than a few years. For example -  my stove, refrigerator, espresso machine, clothes washer and dryer are all more than a decade old and perfectly functional. There is no software to speak of, & the electronic and mechanical parts are still available and replaceable. Likewise, I have two cars that are approaching 15 years old and still working fine. Neither has ever had an issue with the ‘blacks boxes’ on which they are somewhat dependent, neither has had a software-related defect, and if I keep doing basic maintenance and can keep them from rusting, both could be made to last a few more decades.

On the other hand, I have two other vehicles that are new and heavily dependent on software – so much so that in three years I’ve had one recall for a software bug that would have been pretty significant had I hit it while going down the road, and one software related recall that would have toasted my 4wd transfer case had I hit the bug under the right conditions. I also have a vehicle that could potentially last decades, but because some of it’s functionality is tied into current generation smartphones, I expect that if it’s still around I’ll see those functions stop working at some point in time.

There are two factors that I consider when looking at long-term purchases. First, software is always broken. It’s broken when it ships, it’s broken every time you use it, and it’ll still be broken a decade from now when you need it to make your car or appliance work. All software has bugs, and many of those bugs are not uncovered until long after the vendor stopped maintaining the software. Decade-old bugs are found pretty regularly, and few vendors maintain the ability to re-compile and distribute updates for decade-old devices. Any functionality that is dependent on either of the major smartphone OS’s is also time-limited, as vendors simply don’t maintain software compatibility beyond a few OS versions. Nor can we expect that when Android and IoS no longer dominate the smartphone market like Blackberry and Symbian once did, that vendors will forward port functionality from decade-old devices into the then-current OS.

That effectively sets an upper limit on the long-term viability of any software-dependent device, and unlike electro-mechanical devices, the prognosis for long term repair/maintenance is pretty poor.

Like it or not, we are in an era where much of what we have will be lost - not because of rust and decay - but because we will loose the means of maintaining the software that powers the present.


Popular posts from this blog

Cargo Cult System Administration

Cargo Cult: …imitate the superficial exterior of a process or system without having any understanding of the underlying substance --Wikipedia During and after WWII, some native south pacific islanders erroneously associated the presence of war related technology with the delivery of highly desirable cargo. When the war ended and the cargo stopped showing up, they built crude facsimiles of runways, control towers, and airplanes in the belief that the presence of war technology caused the delivery of desirable cargo. From our point of view, it looks pretty amusing to see people build fake airplanes, runways and control towers  and wait for cargo to fall from the sky.
The question is, how amusing are we?We have cargo cult science[1], cargo cult management[2], cargo cult programming[3], how about cargo cult system management?Here’s some common system administration failures that might be ‘cargo cult’:
Failing to understand the difference between necessary and sufficient. A daily backup …

Ad-Hoc Versus Structured System Management

Structured system management is a concept that covers the fundamentals of building, securing, deploying, monitoring, logging, alerting, and documenting networks, servers and applications. Structured system management implies that you have those fundamentals in place, you execute them consistently, and you know all cases where you are inconsistent. The converse of structured system management is what I call ad hoc system management, where every system has it own plan, undocumented and inconsistent, and you don't know how inconsistent they are, because you've never looked.

In previous posts (here and here) I implied that structured system management was an integral part of improving system availability. Having inherited several platforms that had, at best, ad hoc system management, and having moved the platforms to something resembling structured system management, I've concluded that implementing basic structure around system management will be the best and fastest path to…

The Cloud – Provider Failure Modes

In The Cloud - Outsourcing Moved up the Stack[1] I compared the outsourcing that we do routinely (wide area networks) with the outsourcing of the higher layers of the application stack (processor, memory, storage). Conceptually they are similar:In both cases you’ve entrusted your bits to someone else, you’ve shared physical and logical resources with others, you’ve disassociated physical devices (circuits or servers) from logical devices (virtual circuits, virtual severs), and in exchange for what is hopefully better, faster, cheaper service, you give up visibility, manageability and control to a provider. There are differences though. In the case of networking, your cloud provider is only entrusted with your bits for the time it takes for those bits to cross the providers network, and the loss of a few bits is not catastrophic. For providers of higher layer services, the bits are entrusted to the provider for the life of the bits, and the loss of a few bits is a major problem. These …