“Software is Eating the World”…
I’m starting a new blog to start the new year of 2023, and this is the inaugural post!
A top headline in the US in the final week of 2022 was the collapse of service by Southwest Airline. It received massive coverage from traditional news media and on social sites since it coincided with lots of air travel during the year-end holiday season, with special focus on the aged software system that the airline relied on.
Given that, you’d be forgiven for missing another article from the New York Times about changes in the ‘tech’ workforce. In it, authors Steve Lohr and Tripp Mickle report that the 2022 year of layoffs in the sector has initiated a shift wherein former employees at headline-grabbing companies like the FAANG Gang are moving out of the sector and into others like agriculture, health services, or manufacturing. The conceit, however, is that the businesses that populate these ‘older’ sectors have been transforming themselves to utilize more software and therefore resemble more and more the ‘tech’ sector in their modes of operation. ‘Tech’ and the rest are converging and the layoffs have accelerated one dimension of that transductive process.
What interests me in this shift isn’t that older companies are trying to use new technologies to improve their business outcomes. That’s how capitalism works. Instead, my interest was piqued because of what this may signal for the future of Resilience Engineering in software. David Woods (with David Alderson), Laura Maguire, and John Allspaw, amongst a host of others working in software, have perceived the importance of teaching software service providers how to perform resilience and therefore offer a service people can rely on, and which they can use to produce safety in their lives.
One thing that people moving from the ‘tech’ sector into others will need to grapple with is learning these new-to-them domains. In order to create and sustain good services (and avoid what happened with Southwest) they’ll need to let go of established knowledges and practices and collaborate with those with long-time domain experience. They’ll need to learn from and follow the lead of those experts who already work in these sectors and avoid adopting a technocratic (what Wears and Sutcliffe call “scientific-bureaucratic”) approach. That local knowledge will be key to producing a resilient system because it will teach those creating the new software services (which are, of course, meant to serve and not dictate or direct their human partners) how to make a good “team player” that operates in tandem with people.
This is where those of us who practice Resilience Engineering in software are really lucky. The safety scientists that Resilience Engineering draws upon have spent many years working in these other domains before turning to the ‘tech industry’ per se. They and other related researchers in Science & Technology Studies have produced a sizeable body of work which studies the messy middle between the “social” and “technical” sides of the equation. We have all of that to draw upon and to contribute to ourselves as we change the domains by way of acting in and on them. And it makes the work we’ve been doing crucial: our taking seriously our responsibility to produce safe systems has been preparing the way for software operators to move into these other domains and to learn how to perform resilience there.
So as 2023 gets underway remember the bigger picture of what we’re doing and keep on learning and talking and pushing for better practices. It looks like we’re heading for the big time.