A Glitch in the Matrix

Su and Roger take a light-hearted look at why your Code doesn't always work as you expect.

What do being shut out of your bank account, not being able to connect your smartphone to your screen in your new car, failures in the US benefits systems, the mass leakage of personal data, and chaos in airline booking systems all have in common?

If you guessed "Legacy IT Systems" you'd be right. We've all been there! That buggy old "Legacy System" just doesn't do what you want it to any more. The Powers that be say there's barely enough money to fix it, let alone replace it, so you just get used to working around it.

When the State of New Jersey's Disability Automated Benefits System crumbled under the weight of all the newly created jobless due to COVID-19, the State Governor went so far as to call for COBOL Programmers to voluntarily come out of retirement to fix it!

In our experience, even an operating system that hasn't been supported for a year or so (Windows 7) won't always play nice with modern internet security, and don't get us started on Vista!

Yet Governments banks and major corporations worldwide continue to rely on systems that in some cases pre-date the internet written in Programming languages that have long ago fallen into disuse, on operating systems that are no longer supported by their manufacturers, for some of their most basic functions.

There are reasons for this. IT projects are expensive, budgets are tight, and the temptation to patch, upgrade and fix the legacy system, rather than start from scratch is understandable. Old systems often work just fine, doing what they were designed to, the problem comes when they are upgraded piecemeal when what they are needed to do is not what they were designed to do. If the information handled by the legacy system is critical to day-to-day operations, replacing it can cause even bigger problems, in today's 24-hour society.

But despite their complexity and seeming omnipotence, Computer systems don't do what you WANT them to do. They do what you TELL them to do. Or rather they do what some long-forgotten Developer told them to do when you do the thing you just did.

And Developers are people.

If you're me, you grumble about it and find a workaround. If you are the original System Architect or Developer, you might be many contracts, several jobs or a major life-evet or two away from the problem by now. If you're Roger, you might be tasked with having to fix it!

So, how do you know when your old familiar system is becoming outdated? Not just a bit clunky, but no longer fit for purpose? Well, staff developing workarounds is one sure sign. Having multiple systems and silos that don't integrate or talk to each other is also pretty indicative. Is your documentation current? Is the system updatable and future-proofable? And do you know who you could call in to fix it if a problem became mission-critical?

Things become legacy because they are built and then not adequately maintained. Like your new car - you would expect to service it, replace any lubricants and fluids, put it through its MOT when required, change the tyres, and sort out the brakes. All fairly little bills, compared to the initial cost of the thing, all designed to prolong its life. If you drove your car out of the showroom and didn't do any of that for ten years, or even just fixed things when they failed utterly, how long would you go before its safety and usability were compromised? And if everybody did that, how long before all the garages went out of business, and you had to buy a new car every time something went wrong? And even for your shiny new car, even if you do all of that, there comes a time when it becomes beyond economic repair as a daily means of transport. If you are smart, you plan for that, and start budgeting for a new car, long before that happens.

It's amazing how many businesses drive their new computer system away from the showroom, say "thank you very much" and stop investing in it, then complain a couple of years down the line when it hasn't kept up with the fast-moving world of modern technology, and blame the Developer.

Of course, the best thing you can do is to prevent your system from becoming legacy in the first place. This involves regular investment in maintenance, updating your system, checking if it is still meeting your needs, and adding new features or integrations if it doesn't. A quality bespoke system with robust system architecture could last you many more years with some occasional investment, and the regular bills will be smaller and easier to pay for than just leaving things until they become critical.

So, if your system is getting a little clunky? Could it need a service? Or a shiny new integration with your accounts system? Maybe it needs a bit more than that?

Now, with your two-year-old car, would you take it to the cheapest mechanic you can find? Like some guy in a lock-up, who sources his parts from the breakers yard? (You can tell I've driven old cars, can't you?)

This is where the "bus factor" comes in. Because your new IT system is probably more like a custom-built car than a family saloon. If it has been built by one person, an employee, or a freelancer, who is the only person who understands it, if they get run down by a bus, your bus factor is one, and you have a problem.

Ways to increase your "bus factor" include having a team involved in the project, good documentation, pair programming, robust but agile project management, and regular maintenance and updating. You want a stable team with a track record, that you can build a relationship with, who can get to know your system, and maintain your investment in optimum condition.

A bit like taking your car to a reputable garage, with a skilled team of mechanics, who understand both new, custom, and vintage cars? Who test and document their work, communicate well with the customer, and are compliant with relevant legislation and best practice.

If you are Gamma Science, you make sure that there is a bit of built-in redundancy, that more than one person knows how any system is designed and works, and that someone is tasked with keeping the customer in the loop. Because Developers do leave, eventually, though our team is as stable as it gets, (We haven't had a proper farewell party for a decade!)

And if you are employing a company to look after your mission-critical investment, that is what you want.

So when you are planning your project, remember, Software is for Life, not just Christmas.