Your Code Might Stick Around: Windows 3.1 Killed an Airport

Software development is not a trivial task. Anyone who has designed software systems or written code will assert this, but apart from the difficulty of programming a software product that is stable (as much as is possible), bug-free, and satisfies requirements of the client, there remains another factor which is often overlooked. This factor is time. How will code designed this year operate in 20 years time? How does that code manage with its current hardware, and does it make provision for future software upgrades? While many may not stop to consider what their codebase will behave like 2 decades on, the principle is not uncommon, especially when considering OS software.

The XP conundrum

Those who works in a large organizations often have reasons to malign their IT infrastructure. Whilst consumer computers and networks are usually fairly reasonable about jumping ship to the newest operating systems from Microsoft, (and others in the market such as Apple’s OSX, and various Linux distros), the enterprise is comparatively glacial, grinding along often years after consumers have moved on from an ageing operating system. No situation is likely more true than with Microsoft’s Windows XP, with its original codebase dating from 2002 (ignoring service pack releases over the years), that green Bliss hill with rolling blue clouds is often still visible at large corporations on desktops’ wallpapers.

Close to 2 years after Microsoft’s extended support period expired, some of the biggest enterprises only now are beginning the switch to Windows 7, just as Windows 10 gets its November update. The specialized industries are often worse: according to manufacturer NCR, bank ATMs were 95% Windows XP as of the end-of-life date (Europe’s numbers were <1% Windows 7), but South African banks were remarkably up-to-scratch, with most of them having upgraded their ATMs to Windows 7 by late 2014. As of just this week however, the US’s Navy decided to skirt the almost 2 year old deadline issue completely by paying Microsoft to keep supporting Windows XP on their naval vessels and systems.

What is the Relevance of Code Obsolescence?

So why is this relevant to the creation of code, and why do corporations drag their heels in upgrading? The leading cause: compatibility. Specialized code designed for specific purposes (missile targeting, ATM software, industry control software) often isn’t compatible with newer versions of operating systems to enter the market. Consumer-grade popular software has a workaround; most companies simply release compatibility upgrades for their software for the latest OS release. When your code requires extensive testing and full support for the hardware of the day however, you might find that it becomes cheaper to, say, keep using an archaic OS, with code written many years ago, which will work, than to rewrite the codebase to support something less prehistoric.

The problem with such an approach is when things go awry; what happens when a programmer 20 years ago writes code that will do the job at the time, but perhaps doesn’t consider the consequences of an out-of-place brace, or a fault condition that might never happen? This situation in fact faced officials at Paris’ Orly airport recently. They make use of software called “DECOR” which details the visual range pilots will have when they land on the runways at the airport. As on that particular day, when the visibility is poor, the system is essential. However, for an entire day, the airport had to halt all flights temporarily because the DECOR system went down, thanks to a computer running code from 1992 – Microsoft Windows 3.1.

For the younger readers who have perhaps never even been exposed to the antiquated operating system, this is surprising. An airport uses computers from the early 1990s with software as old, to run its operations? Compatibility aside, lack of maintenance and the simple fact that nearly nobody knows how to maintain over two-decade old software (as was the case with the French failure at Orly) leads one to wonder about the ramifications of pre-Y2K code, and (for South Africa anyway) pre-Internet OSes.

What is the relevance of this situation? Firstly, the difficulty of upgrading complex and mission critical code platforms and applications specifically suited to some use-case, is often underestimated. Just as importantly: quick and dirty code fixes implemented may work now, but remember: the code might just be around for some time. That’s why it’s vitally important to make sure the code is of reasonable enough quality when it’s designed and tested to not, for example, grind airport operations to a halt two decades on. Lets hope Airports’ Company South AFrica (ACSA) sets the bar at least at Windows XP for their airport systems. Windows 7’s UI seems to be more prevalent at OR Tambo than in recent years though, which, for now at least, is definitely an encouragement.

Archaic code jokes aside, if you’d be interested in coding, or how to write code at least the right way, check out Hyperion’s offerings and perhaps get started today. Comment with your views on this article in the comments section below, and follow Hyperion Hub developments in the future if you’d like to see more articles like these for the South African market.