When Hardware Drives Software Upgrades

8006701A-85B8-4391-BD36-487B35755676

What’s your favorite version of Microsoft Windows? Is it Windows 10? Maybe it’s Windows XP? Windows 95? Odds are good that you have one version you appreciated more than most. Windows XP, Windows 7, and Windows 10 tend to rank high on the list. Windows ME and Windows 8 seem to rank pretty low. Yet, for all their impressive love and all the users clinging to them we don’t really use anything other than Windows 10 any more.

You might be tempted to say that the OS isn’t supported any longer so there’s no reason to run it. Yet we still drive vehicles that are no longer under warranty. We still buy classic cars that are older than we are and put parts in them to keep them running. Why is software different? What drives us to keep needing to upgrade our programs?

You might be shocked to learn that the most popular reason to upgrade software is, in fact, driven by hardware. It’s not the memory requirements or the fancy new user interface that drives people to move to the new platform. More often than not it’s because a new piece of hardware has requirements that only work on the latest version of the system.

It happened to me once or twice. I can distinctly remember needing to go out and buy a new printer to replace some cheap HP Inkjet I purchased for a project because when I upgraded from Windows XP to Windows 7 the drivers didn’t support the move. Why spend money writing new drivers for a cheap printer when you could just make people go out and buy another new cheap printer? I swear that’s what happened. And, of course, the most expensive the device you purchase the more likely it stays supported, right?

The Lords of COBOL

By now I’m sure you’re all familiar with the little tidbit of information that most of the world’s insurance companies run their databases on ancient mainframes. Why? Well, most of their software still requires COBOL to run. Large organizations don’t like to move to new platforms very often. It wasn’t that long ago that Southwest Airlines moved to a new booking system because the old one only had two days you could schedule flights – Monday through Friday and Sunday. If you scheduled a flight for Monday through Friday you had to have the same flight at the same time every day no matter what. It’s even widely believed that part of the reason that United Airlines merged with Continental was because they wanted to switch to a better booking system.

Why do companies keep these systems around? It should be easy to just migrate off of them, right? Well, reality is that between the sunk cost of operating a mainframe for years and patching the software that you’ve built to operate your business the desire to move to something else isn’t always a driver. After all, if it ain’t broke why fix it? Companies can keep maintaining old systems as long as someone sticks around to keep the lights on. I can remember working with a number of IT professionals over the years that had their jobs mostly because they were the final remaining mainframe wizard that knew how to put the system into maintenance mode or remembered the magical incantations to reboot the old machine after a power failure.

Alas, nothing lasts forever. The current pattern seems to be pretty standard. The old wizards finally decide to retire. They’ve had enough and they’re ready to move to somewhere warm and enjoy not working. The management keeps the lights going because it’s not that hard, right? It would take way too much to rewrite the software or move people to a new platform. Until the day when the system stops working. The day when everything doesn’t come back up. Then it’s panic mode. Was that just the database? What if it’s the actual hardware. Do they still make parts for this? Does anyone even know what this button does? Eventually either the hard decision is made to cut over somehow or an exorbitant amount of money is paid to the former operations people to come back and get things running again long enough to figure out how to keep this from happening again. And if you think you’re going to be able to train a developer to just pick up where the grizzled old wizard left off, good luck. Go find a COBOL training course somewhere. I’ll wait.

Modern Makers Make Mistakes Too

If you think that the modern era of cloud development is any different than writing FORTRAN or COBOL on a mainframe you’ve got a nice set of rose-colored glasses. We’re locking ourselves into the same patterns of thought that brought on the monoliths we’re currently trying to tear down. Every time you enable a feature that only works on one cloud platform or you choose to develop in a hot new language that isn’t fully supported everywhere you’re putting up a barrier that will eventually lead to you making hard choices.

You know what’s different this time, though? You don’t have the luxury of a position where you get to be the wizard that knows how to keep the lights on. As the article above mentions, the race is on to get the COBOL migrated to a modern platform that allows integration with languages like C# and Java. Do you believe that having platforms like that means you’ll get to a point where you can be the last remaining person around that remembers what crazy setup you used to minimize the number of containers an app was using? Or do you think it’s more likely they’ll just fire you, figure out how to integrate your legacy code into a new platform, and go on painting themselves right back into corners?

Hardware is the last true driver to keep people moving along into a place where they are forced to do things the right way. If your hardware doesn’t support something you don’t do it. If you need to ensure that your code is portable you don’t bake in features that require specific hardware or you create a situation where you’re tied to that platform forever. That’s why cloud is a bit scary in my mind. Because you’re agnostic from the hardware. You can do whatever you want without limit.

Want to write software that requires the use of hundreds of processing threads? You can do it because why not? You aren’t limited to just one chip any longer. Want to eat up tons of memory and storage? Go for it. You get to use as much as your credit card can hold. Now the bounds of a programmer’s imagination is no longer limited to physical hardware limitations. If you don’t believe me then ask yourself why there are apps on the App Store today that are bigger then the entire amount of storage that the original iPhone was capable of. Sure, hardware brought us to this point. But ditching the hardware for the magic of the cloud means there isn’t anything holding back those that want to build the biggest, burliest, baddest application they can!


Tom’s Take

Somewhat ironically, I’m not really that worried about the cloud letting people build ugly things to their hearts’ content. Why? Just like terrible movie directors, once you’ve removed their limitations you expose their vulnerabilities and they build something that is unsustainable. Build the biggest app you can. You’ll find out that it collapses under its own weight. Even the promise of the mythical giant virtual machines with 1 TB of RAM haven’t made them materialize. Why? Because it turns out that removing restrictions just enforces them through trial and error. If you have to build small because you can’t get crazy due to hardware you’re held back by external forces. But when you are held back because you tried it that way the last time and you failed by creating an app that takes ten minutes to load you learned your lesson. You get leaner and better and more portable next time. And that’s the kind of driver that makes software and hardware better for us all.