An Ode to Old Tech: 4 Lessons Learned from Legacy Software
After 6 years in application support, it was finally time for me to move on and specialise. Of course, it's exciting, and the journey from jack-of-all-trades to specialist will be a long and interesting one, but it’s daunting, too, and I must admit I do sometimes miss the variety and insanity of that world. Looking back on this though, I couldn't help but reflect on how much I've learned in my career so far in the IT industry - and how much of those learnings that I owe to legacy applications and software. What has gone before us can be a great teacher for what lies ahead, which is why I decided to lay out some key takeways that I have gained from the last 6 years, and how they have helped me to transition into my newest role:
1. Expectation vs Reality
As a graduate, I was full of excitement and expectation; dreaming about all the cool new things I would soon be building. I had solid Java and SQL skills, but was eager to learn so much more. In the interview, I heard all about the broad variety of technologies and customers and industries Ergo dealt with and could not wait to start. I wanted to build mobile apps! I wanted to work with all the latest and greatest technologies.
Anyone who's ever worked in this kind of role can probably see where this is going…
In my first week at Ergo, I was a little taken aback one day when a pile of dusty manuals flopped onto my desk. I was asked to read through them, and told I needed to get up to speed on this software suite before heading to a customer site to join, shadow, and ultimately take over from, a colleague who was based there.
2. Finding the Fun
This wasn't exactly the shiny, new-fangled stuff I had expected but, determined to do a good job anyway, I powered through them. I followed along with all the setup and configuration steps, wrangled with the "compatibility issues", and finally got it running for my first real look; It was some seemingly ancient, WYSIWYG, document-templating software. Behind the somewhat glitchy, off-grey, windows-95-looking UI was an archaic language my colleagues would only refer to as a "dark art".
As I continued to work through my manuals and fiddle with .ini files, I remember eavesdropping enviously on other developers sitting nearby. They talked about websites and apps, plugins, widgets, Big Data, the Cloud… “Someday,” I thought to myself.
As I got up to speed, ‘though, I realised I was actually having fun. I quickly learned to love the thrill of convincing this little beast to do my bidding. I remember being impressed by the power it had for such old software: it was clunky, but reliable; a little ugly, but effective; simple, or as complex as you needed it to be. Configuration could be tricky but, after that, it would “just work”. It was remarkably dependable. No wonder many of our customers were reluctant to give it up.
3. Defence Against the "Dark Art"
I arrived at the customer site and spent several months supporting this software and working, as part of their IT team, from requirements through to release. In that time, many of the changes they needed forced me to peer behind the UI’s curtain into that “dark art”. It looked like a primitive attempt at OO; a series of lines of strange characters, dots and slashes, a syntax like nothing I’ve ever seen before or since. Starting with small tweaks here and there to what the UI wrote for me (and a lot of trial and error), I progressed to more and more complex changes until I could read, manipulate, understand, and even write it myself. It was magic – like that first “click” moment you get learning to code for the first time.
One day, there was a requirement for something the customer had wanted for a while, but that they knew it “couldn’t do”. Like any good developer, I trawled through online forums trying to find someone, anyone, who had come across a similar challenge in the past, but this thing was old, and there was no help to be found. In fact, all I did find was a single comment on an abandoned thread (complete with tumbleweeds) confirming it was not possible. But I was young, stubborn, and didn’t know any better, so naturally I was convinced I could do it. Luckily, about a week or two later, I managed to prove it.
I spent about a year with them before moving on to support other customers, and eventually they moved on, too, to a more modern product to suit their evolving needs. Since then, I’ve worked with old stuff, new stuff, ugly stuff, cool stuff, and everything in-between. I’ve learned a lot about the quirks of older systems, about infrastructure, and a range of other things that I never set out to learn, but that will stand to me and help me be a more well-rounded, conscientious developer.
4. "Legacy" is our Heritage
Software development is decades old. In an ideal world, sure, we'd all work on the fun, modern, “sexy” stuff all the time. Many people loathe the term “legacy”, and I can't exactly blame them, but can't fully agree, either. Sure, it’s grim sometimes, but it can be fun and very rewarding, too. To this day, that impossible function is still one of my proudest achievements. I don’t know if I’ll ever come across a language or challenge as difficult or weird as that again but, if I do, I’ll say bring it on!
So what's next?
Working with legacy code and software can be baffling and unpredictable, frustrating and slow, but it broadens and deepens your experience, makes learning new languages seem like a luxury, and helps you hone skills that simply can't be learned any other way. It’s our heritage as developers. My role has changed; I’ve left support’s school of hard knocks now to join a dev team that’s looking to the future, moving into new, exciting, emerging areas and technologies. I need to get caught up fast, and specialise, too, but I won’t forget where I’ve come from. I’m excited to finally work on more of the stuff I’ve longed for, but there’s a lot that I will miss. Support has prepared me to take on anything, and I wouldn’t trade that experience for anything in the world.