What Happens to Old Software?

From BASIC to Modern Challenges

The BASIC programming language recently turned 60 years old, which kind of put into perspective my own woes trying to update a roughly decade-old Rails project. I actually started my coding journey with BASIC on an old Apple IIe at my elementary school and as long ago as that was, BASIC was a relic even then. I didn’t know it would prime me for a job in software development (as an 8 year-old, I probably imagined I’d be something like a clown or a stunt-man when I grew up), but BASIC’s simple, straightforward syntax introduced me to some of the foundational concepts of computer programming like variables, data structures, and control flow. Fast forward a few decades and here I am professionally living and breathing those very lessons. My current project has me shepherding a codebase originally written about 15 years ago – and left mostly alone for the past 5 – through the last few versions of Ruby on Rails to get it up to date. But what is it about BASIC that allowed it to endure for as long as it did and why does the work I’m doing now on a project a quarter of its age feel more like archaeology than programming? What happens to software as it ages and what does “up to date” mean in this context?

The Enduring Legacy of BASIC

BASIC was born of a different era, back when extensively-trained professional engineers wrote most code in low-level languages like Fortran and COBOL. The Beginner’s All-Purpose Symbolic Instruction Code programming language, however, was made specifically for students and amateurs. It wasn’t the first language trying to make programming more accessible, but it caught on at Dartmouth College and started to spread to other universities and high schools. From there, it found its way into a new class of computers that normal people could own and run in their own homes: personal computers. A whole new generation of users and programmers suddenly had a way to use and write software and this led to a huge proliferation of games and applications, many written in BASIC. You can browse and even use many of these courtesy of the Internet Archive’s software library.

A Journey Through Time: From Oregon Trail to Modern Challenges

One classic of the time was Oregon Trail, played by countless students in computer labs and family rooms all over the country. Here’s a chunk of the source code, written in BASIC:

4700 REM ***MOUNTAINS***
4710 IF H <= 950 THEN 1230
4720 IF RND(-1)*10>9-((M/100-15)^2+72)/((M/100-15)^2+12) THEN 4860
4730 PRINT "RUGGED MOUNTAINS"
4740 IF RND(-1)>.1 THEN 4780
4750 PRINT "YOU GOT LOST---LOSE VALUABLE TIME TRYING TO FIND TRAIL!"

Modern web applications are a far cry from a text-based adventure that can fit in a single file, but some concepts hold. Updating a legacy codebase is not unlike wandering through rugged mountains, getting lost, and losing time trying to find the trail you were following. But one of the main reasons for that, I think, is that coding is a much more social practice now than it was in the BASIC days. Communities grow, change, share and pass along fashions and trends; modern software engineering is no different. You can’t chase every style that comes along, but if you don’t make at least a minimal effort to keep up, you’ll find yourself left behind, isolated and excluded. Software that isn’t updated suffers the same fate. It becomes incompatible and vulnerable and undesirable.

The Nature of Software Aging

In theory, software shouldn’t wear out the way mechanical things do because it exists in a symbolic, or electronic at least, space where physical degradation isn’t a factor. On some level, that intuition holds; software operating in highly isolated, controlled environments can absolutely run for very long periods of time. We see this in certain industries where stability is key. In these contexts, it’s possible that the core functionality is preserved on the existing legacy codebase, while new interfaces are layered on top to allow modernization without sacrificing the stability of the underlying system. You can see a biological parallel to this in the way evolutionarily old brain structures for controlling things like our parasympathetic nervous system (think heartbeat, breathing, digestion) have been conserved (ie, not messed with), while newer structures like the prefrontal cortex for things like language and cognition have been layered on top.

The Challenge of Keeping Up

But, then again, if you aren’t the Department of Defense or some other massive organization with nearly unlimited budget and your software isn’t depended on by millions of people to keep their lives safe and secure, you might find that it lacks the gravity to force any potentially externally integrated systems from deferring to your archaic or increasingly unconventional (as convention moves on) needs. And internally, the software libraries you depend on likely will become less and less compatible with your core codebase. Modern software depends heavily on third-party libraries shared amongst communities of coders. As libraries add new features and fix existing bugs or security vulnerabilities, integrating with them will necessarily require updates on your side of the API. If your organization doesn’t have the resources or expertise to keep up with those changes, you’ll find yourself left behind by the community. This isn’t always immediately a problem, but what tends to force the issue is the security vulnerabilities, bugs that hackers can exploit to access data and functionality meant to be kept private. As these are found, published and exploited by bad actors, your software can slowly but surely become an easy target.

The Present Task: Updating a Legacy Codebase

Which is where I find myself today: updating a legacy codebase. It’s not a massive application and has been soldiering along fairly well without significant updates for several years. In that time, however, a lot has changed and the server’s operating system, the backend application framework and frontend application framework are all several generations behind the current community standards. Getting the codebase and its support systems up to modern versions has been a bit of a history lesson as I’ve had to retrace the steps of the various open source projects and communities, learning about the changes they’ve made, mistakes they discovered and the tradeoffs they accepted in the name of progress along the way.

Conclusion: The Ongoing Journey

On some level, I’m right back in my elementary school computer lab, following along on a virtual journey that illustrates the travels and travails of my forebears. Old software needs love and guidance. Sometimes that means careful and vigilant protection, with layers of abstraction and modernization accreted around a highly conserved core. But more commonly, that means shepherding it along as the community migrates to greener pastures and newer features. It gets lonesome and dangerous out there if you find yourself left behind, but catching up isn’t impossible; a well-caulked wagon and a decent test suite can help you ford some pretty major version bumps and you’ll be up to date in no time.