Last week's news that the U.S. military was retiring a 50-year-old system of 8-inch floppy disks that helped control the nuclear arsenal reminded me of my own brush with outdated technology that could have led to Armageddon.
I was waiting to be interviewed by the History Channel for a special on the early days of the personal computer and was sitting on a couch at the front of a warehouse at Moffett Field that was the temporary home for items that now populate the Computer History Museum down the road in Mountain View, CA. In front of me was a coffee table that consisted of a round piece of clear plexiglass on top of a large, hollow cylinder full of wiring.
Was there a story behind that cylinder? I asked the museum curator.
Oh, he said, that's the guidance system from the nosecone of a Minuteman missile from the 1960s.
Yikes. That thing was supposed to accurately drop a nuclear warhead on a specific spot in the Soviet Union? It looked like one good kick or bit of turbulence would have dislodged enough wiring that the warhead would have landed on Tokyo, or Topeka, or would have just blown up in the missile silo.
But that nosecone turns out to be a good metaphor for how to handle information systems that simply can't lead to an error—including many in insurance.
Now, I'm not conflating any insurance error with Armageddon—no matter how much General Electric's miscalculations on long-term care might feel like doomsday for a company that long was one of the world's most-admired. But the long tail of many insurance contracts creates unusual pressure to avoid mistakes, as do regulatory watchdogs and the desire to treat customers as well as possible in their moment of need, when they have a loss and file a claim.
So, let's look at that nosecone.
The wiring was an aging technology even when implemented in the nosecone I saw and became positively antiquated as the years went along, given that guidance systems, driven by computer technology, have doubled in capability roughly ever year and a half since the '50s. But the wiring had been thoroughly tested, and it worked, once it was "ruggedized" enough to withstand the rigors of traveling through space. Sure, new guidance systems were demonstrably better, but would you bet the defense of the U.S. on their reliability? The fate of the world?
The same concern drove the technology decisions behind the moon landing in 1969. My microwave oven has far more computing power than Apollo 11, but the mostly hard-wired technology for the lunar mission had been tested in space, so advances in technology could wait for later programs.
Silicon Valley, despite its ethos about being on the cutting edge, sometimes takes the same, conservative approach. When I covered Intel for the Wall Street Journal, an executive described for me a process the company calls Copy Exactly. The idea made no sense at first blush: The company would build a chip-manufacturing facility by exactly copying an existing fab, even though Intel had learned in that existing fab how to correct all sorts of inefficiencies by improving a myriad of processes. Why not build all those updates into the new fab from the get-go? Because all the processes interact, and making a bunch of changes at once led to new sorts of problems popping up. Better to copy exactly and introduce the improvements one at a time, in a controlled way.
How do the military, NASA and Intel approaches apply to insurance?
At a high level, they suggest leaving legacy systems alone as much as possible. Yes, better technology is out there, and I'm sure that the many companies selling new software can make a compelling case for updating, but legacy systems are always a mess.
In the biggest technology transition that I've covered—the move from the mainframe era to "client-server" in the 1980s and 1990s—the quick, big wins went to those that focused less on the server piece and more on the client piece, the front end. Technology advances, driven by all those hungry insurtechs out there, allow for all kinds of ways to make improvements, especially in any process that touches a customer, without having to wade through all the back-end complexity.
Focusing on front-end technologies won't let you save humanity, but you could avoid some thorny issues and produce better results faster.
Cheers,
Paul Carroll
Editor-in-Chief
