Why IT Experts Should Reconsider Doing Things the Same Old Way

Joao Correia

December 12, 2022 - Technical Evangelist

“We are in the process of digging ourselves into an anachronism by preserving practices that have no rational basis beyond their historical roots in an earlier period of technological and theoretical development.”

Seymour Papert, “Mindstorms”, 1980

From the same book, the same page, in fact, where the above quote was extracted comes another story that illustrates this point. The QWERTY keyboard layout came about in the age of typewriters – yes, the clunky old machines that made clickety-clack sounds some decades ago.

It turns out that when you pressed neighboring keys on a keyboard too fast, they would be stuck and you would have to manually unstick them. It would slow you down and probably get your fingers dirty in the process too. So the solution was to invent a keyboard layout where letters that usually followed one another would be physically separated, and QWERTY did just that. A couple of years later, the sticking keys problem was solved at the mechanical level.

Despite the solution to the original problem having been found, we still have QWERTY today.

Patching as a Case in Point

Everyone reading this article will know how important vulnerability patching is. Patching comes up all the time in the everyday activities of IT teams, simply because it’s so key to cybersecurity – but patching hasn’t changed much over the years.

Yes, there’s a degree of automation involved today which didn’t used to be there, because (hopefully!) sysadmins no longer manually log in to each system to patch it and don’t manually reboot systems either. Yet, in principle, patching is still highly disruptive and prone to errors. Patching isn’t agile either, as patches are often applied long after a vulnerability has been made public.

That’s why Jack from accounting complains every week about how chaotic the IT department is going to get just because a patching maintenance window was announced. And he’s not wrong, because the way patching has always been done slows systems down or stops them completely, which means that other stakeholders – including Jack – predictably become unhappy.

At the end of the day, patched systems are more secure, but the resulting disruption also reinforces the view that the IT department is a barrier to business as well as a money sink.

There Must Be a Rationale, Right?

The old way of doing things can be disruptive, but it can also be really, really slow. Going back to our patching example, despite all the effort put into it, the slow month-by-month timeframe of regular patching often means that patches just aren’t applied fast enough to respond to cybersecurity incidents.

And, despite the relative inefficiency and sluggishness of patching, it still consumes a huge amount of time and resources. Ineffective, disruptive, time consuming… you’d think patching was being performed the old way because it’s a reliable and foolproof method. But you’d be wrong.

How many times has it happened where a hapless sysadmin accidentally applied patches to and rebooted all of the organization’s web servers instead of just rebooting the hot spares… simply because they selected the wrong machines in the management console?

That, of course, is the moment when Jack from accounting pipes up again about the revenue loss and how it’s bad for customer relations. Yet again he’s right, and yet again it’s clear that the old ways of doing things are not business friendly.

It’s Too Easy to Dismiss Better Options

You’d have to ask why Jack doesn’t get his way at some point. Why don’t IT experts come up with a solution that involves less IT disruption and lower overall costs? Presumably because there just isn’t a better option?

Here’s the eye-opening fact behind many cases of “our team has always done XYZ process in this particular way.” Oftentimes there’s a proven, trusted alternative that’s just not yet been implemented – possibly because some teams are behind the curve.

Consider our patching example again. When you do your research… well, who’d have guessed, but there is a better way to do patching. It’s called live patching. Sure, some companies have been using live patching for years, and it’s been proven to work flawlessly, but live patching is nonetheless not universally implemented.

As always, the reason is simple: tech teams miss out on live patching because they’re sticking to the old ways of doing things. That’s despite the fact that live patching makes things faster, while also being less prone to error – and all while causing less disruption. Live patching is not just a better way to do things, it’s also a safer way to do things because it so rapidly protects against new threats.

Don’t Resist Change

Raising questions about cutting-edge tech is a valid exercise, but refusing to adopt an improved way of doing things “just because doing things the old way was fine all along” can hold your organization back and – worse – open the door to huge risks.

IT practitioners need to stay ahead of the game in all areas. That includes reviewing and questioning practices we’ve been doing the same way for years. Fail to do this and you give Jack from accounting all the reasons he needs to complain about IT. But, review and improve, and you might just find that you hear a lot less from Jack.

Summary