Travis Colbert

Well-known fact: the US Federal Aviation Administration — the government agency responsible for keeping airplanes from crashing into things — is running on crotchety, decades-old technology.

And we're not talking about decades-old "big iron" mainframes. We're talking about decades-old Windows machines, complete with BSODs, beige cases, and strange, noisy storage devices called floppy drives. The machines are so old that replacement parts cannot be acquired easily.

Why would a government agency with an annual budget of over $19 billion not have upgraded their technology in the last 30 years?

Here's one admittedly oversimplified reason: The devil you know is better than the devil you don't.

Faced with the responsibility of keeping millions of people alive every day, the FAA, over the course of decades, determined that it was safer to stick with the same aging, progressively less reliable technology rather than risk the unknowns of upgrading to new technology.

The expression "the devil you know is better than the devil you don't" describes the tendency to actually feel more comfortable with a known, flawed situation over an unknown situation.

We see it all the time, from our personal decisions to national policy:

• You stay in a job you hate because the unknowns of a new job are scarier.
• A country supports an unpopular, autocratic, or tyrannical leader because the alternative is unknown and just might be worse.

In the case of software development, clients will often stick with a legacy system because the unknowns of a new system are scarier.

We've all experienced it: you've spent weeks developing a shiny, vastly superior feature that saves your clients time and money. That new workflow you've written will literally save the planet and prevent the extinction of the human race. Yet, weeks after deploying your new feature, you find out — usually through some side-channel — that your clients never adopted it and have continued to use that old, clunky workflow.

I admit that my first reaction is usually to take it somewhat personally. For a client to not use the new and improved thing we've built can feel like a rejection of our skills and our expertise. And, since many of us actually rather like the idea of improving people's lives, when our clients don't adopt our new and improved thing, it may feel like a rejection of our genuine desire to help.

But, more often than not, it's not you. It's just the devil they know.

It could be that your clients are in no way doubting your skills or your expertise. It could be that they actually do want to collaborate with you to improve their lives or save the human race. They likely are grateful for your efforts. They may have even been the ones who requested the new feature in the first place.

But, when actually faced with the decision to switch from a flawed but well-known workflow to a new one, they may find it more comfortable to stay right where they are. It may simply be more comfortable to remain cozied up with the devil they know — warts and all — because the possibility of encountering new, unknown and potentially uglier warts is more horrifying.

Additionally, there are often practical reasons for sticking with the devil they know:

• They understand the risks of the known situation and have built contingencies around those risks.
• For production operations, management may be able to schedule processes around known limitations in the system.
• The cost, in training alone, of switching to a new system may be prohibitive.
• Management may be less confident in their workforce's ability to adapt to a new system than they are in your new feature.
• For highly production-driven processes or systems involving human life safety, there may be regulatory or compliance reasons for sticking with the known system.

Besides the above, there is also the posibility that your clients actually tried your new feature but quickly ran into some unexpected friction — maybe a bug or an unexpected new complexity — that made them run back to their previous workflow.

Knowing that there might be psychological and practical roadblocks to adoption can help us set realistic expectations when releasing new features. It can also help us empathize with our clients when they don't immediately jump on board with our new and improved workflows.

Knowing that there might be this fear component at play can also help us direct our energies toward helping our clients overcome their fear of the unknown. Documentation, training, and gradual rollouts can help ease the transition from the devil they know to the devil they don't...

...because we have to be honest and admit that that new feature we've built that will save the human race has a flaw or two of its own. It probably silently and efficiently kills kittens.

As I understand it, the FAA has plans to spend billions of dollars over the next decade to modernize their systems. The flaws and shortcomings of the legacy systems have become too great to ignore. Radar systems were leaving planes blindly hurtling off at 4 miles per minute for minutes at a time. Communication systems were failing. Lives were at stake. The situation itself has literally forced them to finally confront the unknowns of adopting new systems.

We can do what we can to illuminate the path to the unknown for our clients, but ultimately, they have to be ready to take that step. Don't take it personally when they don't.