Software Obsolescence: Why Modernization Doesn’t Necessarily Mean “Modern”

For players in the embedded industry it is easy to forget how large the problem of obsolescence can be, especially beyond the component level. Recently, I was talking to a software engineer who had spent a year doing software modernization, as a result of upgrading a flight navigational system from the original code to Linux.

The reasoning for the transition certainly made sense—the program was having difficulties finding software engineers who could continue to sustain programming that had been implemented during the early 1980s. While the system was incredibly robust and was considered “bulletproof,” it could no longer be supported the way it had been. Under pressure to upgrade, the program moved to Linux, which has a community that affords an active and growing resource for talent.

When I was talking with this software engineer, I heard echoes of the other modernization horror stories that we have heard from our customers. Young engineers had to find experienced engineers (who had not yet retired) who understood the older code and could help translate it into Linux. Older engineers had to spend hours on Linux forums trying to find how to take old functionality and reproduce it in Linux. Teams devoting over a year of long nights and weekends, making sure that software changes didn’t affect old hardware.

It was almost ironic that, in the end, the so-called modernization was really a reproduction of the original system, without any new functionality, because otherwise all the training, documentation, education, and recertification that had gone into generations of pilots would have to be re-done as well.

Modernized? Yes. Modern? No.

Kaye & the GDCA Team