Files
nexus/sreweekly/articles/92/04-the-coming-software-apocalypse.html
2026-09-12 17:23:01 +08:00

11 lines
257 KiB
HTML
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
<!DOCTYPE html><html lang="en" dir="ltr"><head><meta charSet="utf-8" data-next-head=""/><meta name="viewport" content="width=device-width,initial-scale=1" data-next-head=""/><link rel="icon" href="https://cdn.theatlantic.com/_next/static/images/favicon-3888b0e329526a975703e3059a02b92d.ico" data-next-head=""/><link rel="apple-touch-icon" href="https://cdn.theatlantic.com/_next/static/images/apple-touch-icon-default-b504d70343a9438df64c32ce339c7ebc.png" data-next-head=""/><link rel="apple-touch-icon" sizes="76x76" href="https://cdn.theatlantic.com/_next/static/images/apple-touch-icon-76x76-d5accc11b8265af76495fbfa9d38dd3b.png" data-next-head=""/><link rel="apple-touch-icon" sizes="120x120" href="https://cdn.theatlantic.com/_next/static/images/apple-touch-icon-120x120-419ba228184c040a691628d3dd82c206.png" data-next-head=""/><link rel="apple-touch-icon" sizes="152x152" href="https://cdn.theatlantic.com/_next/static/images/apple-touch-icon-152x152-aafde20dd981a38fcd549b29b2b3b785.png" data-next-head=""/><meta name="application-name" content="theatlantic" data-next-head=""/><meta name="msapplication-TileColor" content="#FFFFFF" data-next-head=""/><meta name="msapplication-TileImage" content="https://cdn.theatlantic.com/_next/static/images/apple-touch-icon-default-b504d70343a9438df64c32ce339c7ebc.png" data-next-head=""/><meta property="og:site_name" content="The Atlantic" data-next-head=""/><meta property="og:locale" content="en_US" data-next-head=""/><meta property="fb:admins" content="577048155,17301937" data-next-head=""/><meta property="fb:app_id" content="100770816677686" data-next-head=""/><meta property="fb:pages" content="29259828486,1468531833474495,1061579677251147,457711054591520,370457103090695,1631141167169115,148681772342453,1510507419185410,128344747344340,128377530562508,236061986423933" data-next-head=""/><meta name="p:domain_verify" content="68e1a0361a557708fefc992f3309ed70" data-next-head=""/><meta name="twitter:site" content="@theatlantic" data-next-head=""/><meta name="twitter:domain" content="theatlantic.com" data-next-head=""/><script type="application/ld+json" data-next-head="">{"@context":"https://schema.org","@type":"WebSite","name":"The Atlantic","url":"https://www.theatlantic.com","inLanguage":"en-US","issn":"1072-7825","potentialAction":{"@type":"SearchAction","target":"https://www.theatlantic.com/search/?q={q}","query-input":"required name=q"}}</script><script type="application/ld+json" data-next-head="">{"@context":"https://schema.org","@type":"Organization","@id":"https://www.theatlantic.com/#publisher","name":"The Atlantic","url":"https://www.theatlantic.com","logo":{"@type":"ImageObject","width":{"@type":"QuantitativeValue","unitCode":"E37","value":224},"height":{"@type":"QuantitativeValue","unitCode":"E37","value":224},"url":"https://cdn.theatlantic.com/assets/media/files/atlantic-logo--224x224.png"},"sameAs":["https://www.facebook.com/TheAtlantic","https://twitter.com/theatlantic"]}</script><title data-next-head="">The Coming Software Apocalypse - The Atlantic</title><meta property="article:platform" content="web" data-next-head=""/><meta property="article:category" content="technology" data-next-head=""/><link rel="preconnect" href="https://cdn.privacy-mgmt.com/" crossorigin="" data-next-head=""/><link rel="dns-prefetch" href="https://cdn.privacy-mgmt.com/" data-next-head=""/><script defer="" data-next-head="">"use strict"; function _typeof(t) { return (_typeof = "function" == typeof Symbol && "symbol" == typeof Symbol.iterator ? function (t) { return typeof t } : function (t) { return t && "function" == typeof Symbol && t.constructor === Symbol && t !== Symbol.prototype ? "symbol" : typeof t })(t) } !function () { var t = function () { var t, e, o = [], n = window, r = n; for (; r;) { try { if (r.frames.__tcfapiLocator) { t = r; break } } catch (t) { } if (r === n.top) break; r = r.parent } t || (!function t() { var e = n.document, o = !!n.frames.__tcfapiLocator; if (!o) if (e.body) { var r = e.createElement("iframe"); r.style.cssText = "display:none", r.name = "__tcfapiLocator", e.body.appendChild(r) } else setTimeout(t, 5); return !o }(), n.__tcfapi = function () { for (var t = arguments.length, n = new Array(t), r = 0; r < t; r++)n[r] = arguments[r]; if (!n.length) return o; "setGdprApplies" === n[0] ? n.length > 3 && 2 === parseInt(n[1], 10) && "boolean" == typeof n[3] && (e = n[3], "function" == typeof n[2] && n[2]("set", !0)) : "ping" === n[0] ? "function" == typeof n[2] && n[2]({ gdprApplies: e, cmpLoaded: !1, cmpStatus: "stub" }) : o.push(n) }, n.addEventListener("message", (function (t) { var e = "string" == typeof t.data, o = {}; if (e) try { o = JSON.parse(t.data) } catch (t) { } else o = t.data; var n = "object" === _typeof(o) && null !== o ? o.__tcfapiCall : null; n && window.__tcfapi(n.command, n.version, (function (o, r) { var a = { __tcfapiReturn: { returnValue: o, success: r, callId: n.callId } }; t && t.source && t.source.postMessage && t.source.postMessage(e ? JSON.stringify(a) : a, "*") }), n.parameter) }), !1)) }; "undefined" != typeof module ? module.exports = t : t() }();</script><script defer="" data-next-head="">window.__gpp_addFrame = function (e) { if (!window.frames[e]) if (document.body) { var t = document.createElement("iframe"); t.style.cssText = "display:none", t.name = e, document.body.appendChild(t) } else window.setTimeout(window.__gpp_addFrame, 10, e) }, window.__gpp_stub = function () { var e = arguments; if (__gpp.queue = __gpp.queue || [], __gpp.events = __gpp.events || [], !e.length || 1 == e.length && "queue" == e[0]) return __gpp.queue; if (1 == e.length && "events" == e[0]) return __gpp.events; var t = e[0], p = e.length > 1 ? e[1] : null, s = e.length > 2 ? e[2] : null; if ("ping" === t) p({ gppVersion: "1.1", cmpStatus: "stub", cmpDisplayStatus: "hidden", signalStatus: "not ready", supportedAPIs: ["2:tcfeuv2", "5:tcfcav1", "6:uspv1", "7:usnatv1", "8:uscav1", "9:usvav1", "10:uscov1", "11:usutv1", "12:usctv1"], cmpId: 0, sectionList: [], applicableSections: [], gppString: "", parsedSections: {} }, !0); else if ("addEventListener" === t) { "lastId" in __gpp || (__gpp.lastId = 0), __gpp.lastId++; var n = __gpp.lastId; __gpp.events.push({ id: n, callback: p, parameter: s }), p({ eventName: "listenerRegistered", listenerId: n, data: !0, pingData: { gppVersion: "1.1", cmpStatus: "stub", cmpDisplayStatus: "hidden", signalStatus: "not ready", supportedAPIs: ["2:tcfeuv2", "5:tcfcav1", "6:uspv1", "7:usnatv1", "8:uscav1", "9:usvav1", "10:uscov1", "11:usutv1", "12:usctv1"], cmpId: 0, sectionList: [], applicableSections: [], gppString: "", parsedSections: {} } }, !0) } else if ("removeEventListener" === t) { for (var a = !1, i = 0; i < __gpp.events.length; i++)if (__gpp.events[i].id == s) { __gpp.events.splice(i, 1), a = !0; break } p({ eventName: "listenerRemoved", listenerId: s, data: a, pingData: { gppVersion: "1.1", cmpStatus: "stub", cmpDisplayStatus: "hidden", signalStatus: "not ready", supportedAPIs: ["2:tcfeuv2", "5:tcfcav1", "6:uspv1", "7:usnatv1", "8:uscav1", "9:usvav1", "10:uscov1", "11:usutv1", "12:usctv1"], cmpId: 0, sectionList: [], applicableSections: [], gppString: "", parsedSections: {} } }, !0) } else "hasSection" === t ? p(!1, !0) : "getSection" === t || "getField" === t ? p(null, !0) : __gpp.queue.push([].slice.apply(e)) }, window.__gpp_msghandler = function (e) { var t = "string" == typeof e.data; try { var p = t ? JSON.parse(e.data) : e.data } catch (e) { p = null } if ("object" == typeof p && null !== p && "__gppCall" in p) { var s = p.__gppCall; window.__gpp(s.command, (function (p, n) { var a = { __gppReturn: { returnValue: p, success: n, callId: s.callId } }; e.source.postMessage(t ? JSON.stringify(a) : a, "*") }), "parameter" in s ? s.parameter : null, "version" in s ? s.version : "1.1") } }, "__gpp" in window && "function" == typeof window.__gpp || (window.__gpp = window.__gpp_stub, window.addEventListener("message", window.__gpp_msghandler, !1), window.__gpp_addFrame("__gppLocator"));</script><script data-next-head="">window._sp_queue = [];
window._sp_ = {
config: {
accountId: 1247,
baseEndpoint: 'https://cdn.privacy-mgmt.com',
ccpa: {},
usnat: {},
custom: {},
gdpr: {},
}
}</script><script src="https://cdn.privacy-mgmt.com/unified/wrapperMessagingWithoutDetection.js" defer="" data-next-head=""></script><link rel="preconnect" href="https://01.cdn.mediatradecraft.com/" crossorigin="" data-next-head=""/><link rel="dns-prefetch" href="https://01.cdn.mediatradecraft.com/" data-next-head=""/><link rel="preconnect" href="https://securepubads.g.doubleclick.net" data-next-head=""/><link rel="preload" href="https://securepubads.g.doubleclick.net/tag/js/gpt.js" as="script" data-next-head=""/><link rel="preconnect" href="https://c.amazon-adsystem.com/" crossorigin="" data-next-head=""/><link rel="dns-prefetch" href="https://c.amazon-adsystem.com/" data-next-head=""/><link rel="preconnect" href="https://micro.rubiconproject.com/" crossorigin="" data-next-head=""/><link rel="dns-prefetch" href="https://micro.rubiconproject.com/" data-next-head=""/><script src="https://c.amazon-adsystem.com/aax2/apstag.js" async="" data-next-head=""></script><script src="https://securepubads.g.doubleclick.net/tag/js/gpt.js" async="" data-next-head=""></script><script src="https://01.cdn.mediatradecraft.com/theatlantic/main/main.js?template=article_feature" async="" data-next-head=""></script><link href="https://01.cdn.mediatradecraft.com/theatlantic/main/main.css" media="all" rel="stylesheet" data-next-head=""/><meta name="description" content="A small group of programmers wants to change how we code—before catastrophe strikes." data-next-head=""/><meta property="krux:title" content="The Coming Software Apocalypse - The Atlantic" data-next-head=""/><meta property="krux:description" content="A small group of programmers wants to change how we code—before catastrophe strikes." data-next-head=""/><link rel="canonical" href="https://www.theatlantic.com/technology/archive/2017/09/saving-the-world-from-code/540393/" data-next-head=""/><link rel="image_src" href="https://cdn.theatlantic.com/thumbor/ud_p3Hp5As5Wjz7gZ9GAcZXdObo=/0x187:1997x1227/1200x625/media/img/mt/2017/09/TheAtlantic_CodeFinal3/original.png" data-next-head=""/><meta name="author" content="James Somers" data-next-head=""/><meta property="article:publisher" content="https://www.facebook.com/TheAtlantic/" data-next-head=""/><meta property="article:opinion" content="false" data-next-head=""/><meta property="article:content_tier" content="metered" data-next-head=""/><meta property="article:tag" content="technology" data-next-head=""/><meta property="article:section" content="Technology" data-next-head=""/><meta property="article:published_time" content="2017-09-26T15:10:42Z" data-next-head=""/><meta property="article:modified_time" content="2017-11-16T16:26:59Z" data-next-head=""/><meta name="robots" content="index, follow, max-image-preview:large" data-next-head=""/><meta property="og:title" content="The Coming Software Apocalypse" data-next-head=""/><meta property="og:description" content="A small group of programmers wants to change how we code—before catastrophe strikes." data-next-head=""/><meta property="og:url" content="https://www.theatlantic.com/technology/archive/2017/09/saving-the-world-from-code/540393/" data-next-head=""/><meta property="og:type" content="article" data-next-head=""/><meta property="og:image" content="https://cdn.theatlantic.com/thumbor/ud_p3Hp5As5Wjz7gZ9GAcZXdObo=/0x187:1997x1227/1200x625/media/img/mt/2017/09/TheAtlantic_CodeFinal3/original.png" data-next-head=""/><meta property="twitter:card" content="summary_large_image" data-next-head=""/><meta name="FacebookShareMessage" content="The coming software apocalypse, by @jsomers" data-next-head=""/><meta name="TwitterShareMessage" content="The coming software apocalypse, by @jsomers" data-next-head=""/><link rel="alternate" type="application/rss+xml" title="The Atlantic" href="/feed/all/" data-next-head=""/><link rel="alternate" type="application/rss+xml" title="Best of The Atlantic" href="/feed/best-of/" data-next-head=""/><meta name="referrer" content="unsafe-url" data-next-head=""/><meta name="apple-mobile-web-app-capable" content="yes" data-next-head=""/><meta name="apple-mobile-web-status-bar-style" content="black" data-next-head=""/><meta name="apple-mobile-web-app-title" content="The Atlantic" data-next-head=""/><meta name="sailthru.title" content="The Coming Software Apocalypse" data-next-head=""/><meta name="sailthru.description" content="A small group of programmers wants to change how we code—before catastrophe strikes." data-next-head=""/><meta name="sailthru.tags" content="technology,features,author-james-somers" data-next-head=""/><meta name="sailthru.date" content="2017-09-26T15:10:42Z" data-next-head=""/><link rel="preload" as="font" type="font/woff2" href="https://www.theatlantic.com/packages/fonts/garamond/AGaramondPro-Regular.woff2" crossorigin="" data-next-head=""/><link rel="preload" as="font" type="font/woff2" href="https://www.theatlantic.com/packages/fonts/graphik/Graphik-Regular-Web.woff2" crossorigin="" data-next-head=""/><link rel="preload" as="font" type="font/woff2" href="https://www.theatlantic.com/packages/fonts/graphik/Graphik-Semibold-Web.woff2" crossorigin="" data-next-head=""/><link rel="preload" as="font" type="font/woff2" href="https://www.theatlantic.com/packages/fonts/logic/LogicMonospace-Medium.woff2" crossorigin="" data-next-head=""/><link rel="preload" as="font" type="font/woff2" href="https://www.theatlantic.com/packages/fonts/logic/LogicMonospace-Regular.woff2" crossorigin="" data-next-head=""/><script type="application/ld+json" data-next-head="">{"@context":"https://schema.org","@type":"NewsArticle","headline":"The Coming Software Apocalypse","alternativeHeadline":"The Coming Software Apocalypse","description":"A small group of programmers wants to change how we code—before catastrophe strikes.","url":"https://www.theatlantic.com/technology/archive/2017/09/saving-the-world-from-code/540393/","datePublished":"2017-09-26T15:10:42Z","dateModified":"2017-11-16T16:26:59Z","isAccessibleForFree":false,"hasPart":{"@type":"WebPageElement","isAccessibleForFree":false,"cssSelector":".article-content-body"},"publisher":{"@id":"https://www.theatlantic.com/#publisher"},"mainEntityOfPage":{"@type":"WebPage","@id":"https://www.theatlantic.com/technology/archive/2017/09/saving-the-world-from-code/540393/"},"image":[{"@type":"ImageObject","width":{"@type":"QuantitativeValue","unitCode":"E37","value":1080},"height":{"@type":"QuantitativeValue","unitCode":"E37","value":1080},"url":"https://cdn.theatlantic.com/thumbor/rcwVU6YYyo0y93UdHzou7MHO--Q=/333x0:1666x1333/1080x1080/media/img/mt/2017/09/TheAtlantic_CodeFinal3/original.png"},{"@type":"ImageObject","width":{"@type":"QuantitativeValue","unitCode":"E37","value":1200},"height":{"@type":"QuantitativeValue","unitCode":"E37","value":900},"url":"https://cdn.theatlantic.com/thumbor/1lRzKc7cjwTehI6auY2wbioJZRE=/111x0:1888x1333/1200x900/media/img/mt/2017/09/TheAtlantic_CodeFinal3/original.png"},{"@type":"ImageObject","width":{"@type":"QuantitativeValue","unitCode":"E37","value":1600},"height":{"@type":"QuantitativeValue","unitCode":"E37","value":900},"url":"https://cdn.theatlantic.com/thumbor/T7QNU05oi2SNFmre1SzuR4P1D1s=/0x102:2000x1227/1600x900/media/img/mt/2017/09/TheAtlantic_CodeFinal3/original.png"},{"@type":"ImageObject","width":{"@type":"QuantitativeValue","unitCode":"E37","value":960},"height":{"@type":"QuantitativeValue","unitCode":"E37","value":540},"url":"https://cdn.theatlantic.com/thumbor/ghDkv236UfxsA_WV_ShjsXIq-Mo=/0x102:2000x1227/960x540/media/img/mt/2017/09/TheAtlantic_CodeFinal3/original.png"},{"@type":"ImageObject","width":{"@type":"QuantitativeValue","unitCode":"E37","value":540},"height":{"@type":"QuantitativeValue","unitCode":"E37","value":540},"url":"https://cdn.theatlantic.com/thumbor/-g21VhY08h6EVTY4xldi3KRSqzQ=/333x0:1666x1333/540x540/media/img/mt/2017/09/TheAtlantic_CodeFinal3/original.png"}],"author":[{"@type":"Person","name":"James Somers","sameAs":"https://www.theatlantic.com/author/james-somers/"}],"articleSection":"Technology"}</script><link rel="preload" as="image" href="https://cdn.theatlantic.com/thumbor/iTzwN-qrMZdubIcExn-2pLs7t80=/108x230:1897x1236/1440x810/media/img/2017/09/21/TheAtlantic_CodeFinal3/original.png" imageSrcSet="https://cdn.theatlantic.com/thumbor/6Ln6NcHA-BoP2VR_nwDteVywXn8=/108x230:1897x1236/640x360/media/img/2017/09/21/TheAtlantic_CodeFinal3/original.png 640w, https://cdn.theatlantic.com/thumbor/DhlrPoqTvIdglIRxFSSKNUHqg5E=/108x230:1897x1236/750x422/media/img/2017/09/21/TheAtlantic_CodeFinal3/original.png 750w, https://cdn.theatlantic.com/thumbor/5My8Q2BelrqNVX9AqSZlQrd14Cg=/108x230:1897x1236/850x478/media/img/2017/09/21/TheAtlantic_CodeFinal3/original.png 850w, https://cdn.theatlantic.com/thumbor/y82l57Br304M0irZ_SyHdfyQ9vE=/108x230:1897x1236/1536x864/media/img/2017/09/21/TheAtlantic_CodeFinal3/original.png 1536w" imageSizes="(min-width: 1920px) 1920px, 100vw" data-next-head=""/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/css/fb69cae6b0352231.css" as="style"/><link rel="stylesheet" href="https://cdn.theatlantic.com/_next/static/css/fb69cae6b0352231.css" data-n-g=""/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/css/500a1531cb85b2f2.css" as="style"/><link rel="stylesheet" href="https://cdn.theatlantic.com/_next/static/css/500a1531cb85b2f2.css" data-n-p=""/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/css/538374b17c6bb26e.css" as="style"/><link rel="stylesheet" href="https://cdn.theatlantic.com/_next/static/css/538374b17c6bb26e.css" data-n-p=""/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/css/319bc1259983cfd8.css" as="style"/><link rel="stylesheet" href="https://cdn.theatlantic.com/_next/static/css/319bc1259983cfd8.css" data-n-p=""/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/css/847d20c6ad200358.css" as="style"/><link rel="stylesheet" href="https://cdn.theatlantic.com/_next/static/css/847d20c6ad200358.css" data-n-p=""/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/css/6fd6997b8cc734bf.css" as="style"/><link rel="stylesheet" href="https://cdn.theatlantic.com/_next/static/css/6fd6997b8cc734bf.css" data-n-p=""/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/css/19ae28a8cb1f7317.css" as="style"/><link rel="stylesheet" href="https://cdn.theatlantic.com/_next/static/css/19ae28a8cb1f7317.css" data-n-p=""/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/css/a6cc4a7a6462c4d1.css" as="style"/><link rel="stylesheet" href="https://cdn.theatlantic.com/_next/static/css/a6cc4a7a6462c4d1.css"/><noscript data-n-css=""></noscript><link rel="preload" href="https://cdn.theatlantic.com/_next/static/chunks/8476.695f762283eb3a7a.js" as="script"/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/chunks/webpack-459d7a8ce0f9e787.js" as="script"/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/chunks/framework-b9fd9bcc3ecde907.js" as="script"/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/chunks/main-1e3f07e508c9deb1.js" as="script"/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/chunks/pages/_app-eb71c0d56c56049a.js" as="script"/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/chunks/1851-e6d0404216255e04.js" as="script"/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/chunks/6636-bc98ad1f3cd91596.js" as="script"/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/chunks/3797-f8042da41ece45a6.js" as="script"/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/chunks/2296-0ecf836df9c60165.js" as="script"/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/chunks/5683-10fee38148845c4a.js" as="script"/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/chunks/1790-7d35389f9e543b1d.js" as="script"/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/chunks/4299-a4b3ac3873e55247.js" as="script"/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/chunks/6976-da5685274cf13d59.js" as="script"/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/chunks/1747-9d561606d4c5bdea.js" as="script"/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/chunks/5671-409d5aba090bd11d.js" as="script"/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/chunks/5539-292b7ebdeac3fbb8.js" as="script"/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/chunks/808-25295386c27f4971.js" as="script"/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/chunks/4499-8ce342ce305a927c.js" as="script"/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/chunks/6503-09da97c356ee7944.js" as="script"/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/chunks/9938-950cf6b0a960f8a4.js" as="script"/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/chunks/7010-0e727db2863a9d5c.js" as="script"/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/chunks/4093-be5a4b602dd5c78a.js" as="script"/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/chunks/4219-ddc90b3d511b84e6.js" as="script"/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/chunks/926-0fae957bf31b0a36.js" as="script"/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/chunks/8322-953eb68d75c58cc6.js" as="script"/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/chunks/1066-93aa99a342a17433.js" as="script"/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/chunks/8634-e46cb95aa95ded3e.js" as="script"/><link rel="preload" href="https://cdn.theatlantic.com/_next/static/chunks/pages/%5Bchannel%5D/archive/%5Byear%5D/%5Bmonth%5D/%5Bslug%5D/%5Bid%5D-c0e53763bbf4b5ea.js" as="script"/></head><body><div id="__next"><div data-event-surface="article"><div></div><nav class="Nav_root__HcZek" aria-labelledby="site-navigation" data-event-module="site nav" id="main-navigation"><div class="Nav_mainNav__iPsWc" data-nosnippet="true"><a href="#main-content" class="Nav_skipLink__P4Y5R">Skip to content</a><h2 id="site-navigation" class="Nav_visuallyHide__Lzzui">Site Navigation</h2><div class="Nav_flexContainer__9iJ4H"><ul class="Nav_leftContainer__Xs54R"><li class="Nav_navListItem__l2afO Nav_visuallyHideOnMobile__N9bs2"><a href="/" class="Nav_navLink__34Bol"><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 87.83 134" class="Nav_bigA__c1aIb"><title>The Atlantic</title><path d="M24.48 95.13c-.56 0-.74-.37-.74-.93l13.08-55.88c.19-.94.93-.94 1.12 0L50.09 94.2c0 .56-.19.93-.75.93zM48.22.19a22.54 22.54 0 01-7.66 5.05c-.75.19-.94.37-1.13 1.12l-26.72 112.5c-2 9-4.67 10.66-11.77 11.22a.88.88 0 00-.94.93v2.06a.88.88 0 00.92.93h25.6a.88.88 0 00.93-.93V131a.88.88 0 00-.93-.93c-9.53 0-10.47-2.81-8.6-10.66l4.49-19.25a1.18 1.18 0 011.12-.93h26.74a1.19 1.19 0 011.13.93l5 23.18c1.12 5-.75 6.17-7.1 6.73a.88.88 0 00-.93.93v2.06a.88.88 0 00.93.93h37.62a.88.88 0 00.94-.93V131a.88.88 0 00-.94-.93c-5.79-.56-8.22-1.5-9.34-6.73L49.34.57c-.19-.56-.75-.75-1.12-.38"></path></svg></a></li><li class="Nav_navListItem__l2afO Nav_hamburgerLi__gP6Dn"><button class="NavHamburgerButton_root__OgJkB" aria-expanded="false" aria-controls="expanded-nav" aria-label="Open Main Menu"><div class="NavHamburgerButton_burger__jIWmI"><div class="NavHamburgerButton_box__J5rDn"><div class="NavHamburgerButton_inner__dKlIy"></div></div></div></button><div class="Nav_expandedNav__o5Zj_"><div hidden="" class="ExpandedNav_root__r3hKE" id="expanded-nav"><div class="ExpandedNav_mobileHeader__QEenD" data-event-element="mobile links"><button class="ExpandedNav_searchButton__85mWm" aria-label="Search The Atlantic"><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16" class="ExpandedNav_searchIcon__2EngD"><path d="M15.85 15.15l-5.27-5.28a6 6 0 10-.71.71l5.28 5.27a.48.48 0 00.7 0 .48.48 0 000-.7zM1 6a5 5 0 115 5 5 5 0 01-5-5z"></path></svg></button><div><a class="ExpandedNav_mostPopular__EbSyn" href="/most-popular/">Popular</a><a class="ExpandedNav_latest__zSrBe" href="/latest/">Latest</a><a class="ExpandedNav_newsletters__W83ni" href="/newsletters/">Newsletters</a></div></div><div class="ExpandedNav_container__sDhOz"><div class="ExpandedNav_sections__oGeXo" data-event-element="sections"><h2 class="ExpandedNav_title__C8QcN ExpandedNav_sectionTitle___xWBI">Sections</h2><ul class="ExpandedNav_sectionUl__mLUY1"><li class="ExpandedNav_sectionLi__tZz7K"><a href="/ideas/" class="ExpandedNav_sectionLink__3iXo9">Ideas</a></li><li class="ExpandedNav_sectionLi__tZz7K"><a href="/politics/" class="ExpandedNav_sectionLink__3iXo9">Politics</a></li><li class="ExpandedNav_sectionLi__tZz7K"><a href="/economy/" class="ExpandedNav_sectionLink__3iXo9">Economy</a></li><li class="ExpandedNav_sectionLi__tZz7K"><a href="/international/" class="ExpandedNav_sectionLink__3iXo9">Global</a></li><li class="ExpandedNav_sectionLi__tZz7K"><a href="/national-security/" class="ExpandedNav_sectionLink__3iXo9">National Security</a></li><li class="ExpandedNav_sectionLi__tZz7K"><a href="/category/washington-week-atlantic/" class="ExpandedNav_sectionLink__3iXo9">Washington Week</a></li><li class="ExpandedNav_sectionLi__tZz7K"><a href="/category/features/" class="ExpandedNav_sectionLink__3iXo9">Features</a></li><li class="ExpandedNav_sectionLi__tZz7K"><a href="/technology/" class="ExpandedNav_sectionLink__3iXo9">Technology</a></li><li class="ExpandedNav_sectionLi__tZz7K"><a href="/category/ai-watchdog/" class="ExpandedNav_sectionLink__3iXo9">AI Watchdog</a></li><li class="ExpandedNav_sectionLi__tZz7K"><a href="/science/" class="ExpandedNav_sectionLink__3iXo9">Science</a></li><li class="ExpandedNav_sectionLi__tZz7K"><a href="/projects/planet/" class="ExpandedNav_sectionLink__3iXo9">Planet</a></li><li class="ExpandedNav_sectionLi__tZz7K ExpandedNav_tabletColumnStart__ibBKq"><a href="/health/" class="ExpandedNav_sectionLink__3iXo9">Health</a></li><li class="ExpandedNav_sectionLi__tZz7K"><a href="/category/philosophy/" class="ExpandedNav_sectionLink__3iXo9">Philosophy</a></li><li class="ExpandedNav_sectionLi__tZz7K"><a href="/education/" class="ExpandedNav_sectionLink__3iXo9">Education</a></li><li class="ExpandedNav_sectionLi__tZz7K"><a href="/culture/" class="ExpandedNav_sectionLink__3iXo9">Culture</a></li><li class="ExpandedNav_sectionLi__tZz7K"><a href="/category/comedy/" class="ExpandedNav_sectionLink__3iXo9">Comedy</a></li><li class="ExpandedNav_sectionLi__tZz7K ExpandedNav_tabletColumnStart__ibBKq"><a href="/family/" class="ExpandedNav_sectionLink__3iXo9">Family</a></li><li class="ExpandedNav_sectionLi__tZz7K"><a href="/books/" class="ExpandedNav_sectionLink__3iXo9">Books</a></li><li class="ExpandedNav_sectionLi__tZz7K"><a href="/category/fiction/" class="ExpandedNav_sectionLink__3iXo9">Fiction</a></li><li class="ExpandedNav_sectionLi__tZz7K"><a href="/photography/" class="ExpandedNav_sectionLink__3iXo9">Photography</a></li><li class="ExpandedNav_sectionLi__tZz7K"><a href="/atlantic-across-america/" class="ExpandedNav_sectionLink__3iXo9">Events</a></li></ul></div><div class="ExpandedNav_moreLinks__G4VPb" data-event-element="more links"><ul class="ExpandedNav_moreLinksList__u0bVY"><li class="ExpandedNav_moreLinksListItem__UrTkv"><a href="/archive/" class="ExpandedNav_moreLinksItem__JhFzM"><img alt="" loading="lazy" class="Image_root__XxsOp Image_lazy__hYWHV ExpandedNav_moreLinksImg__IY3fl" src="https://cdn.theatlantic.com/_next/static/images/nav-archive-promo-5541b02ae92f1a9276249e1c6c2534ee.png" width="80" height="80"/><span>Explore The Atlantic Archive</span></a></li><li class="ExpandedNav_moreLinksListItem__UrTkv"><a href="/games/" class="ExpandedNav_moreLinksItem__JhFzM"><img alt="" class="Image_root__XxsOp ExpandedNav_moreLinksImg__IY3fl" src="https://cdn.theatlantic.com/media/games/games_promo_color.png" width="80" height="80"/><span>Play The Atlantic Games</span></a></li><li class="ExpandedNav_moreLinksListItem__UrTkv"><a href="/audio/" class="ExpandedNav_moreLinksItem__JhFzM"><svg width="80" height="80" viewBox="0 0 64 64" fill="none" xmlns="http://www.w3.org/2000/svg" class="ExpandedNav_moreLinksImg__IY3fl"><path fill="#FAF4EB" d="M0 0h63.998v64H0z"></path><path d="M25.267 31.27h-1.171v12.138h1.17a.392.392 0 00.393-.392V31.662a.392.392 0 00-.392-.393v.002zM38.34 31.662v11.354c0 .217.175.392.392.392h1.171V31.271h-1.17a.392.392 0 00-.393.392v-.002z" fill="#000"></path><path d="M44.605 33.479c.106-.69.163-1.398.163-2.12 0-7.343-5.718-13.296-12.77-13.296-7.05 0-12.768 5.953-12.768 13.296 0 .722.057 1.429.163 2.12l-1.413.58v6.56l2.033.834a3.194 3.194 0 001.586 1.65c.411.193.869.305 1.353.305h.34V31.271h-.34c-.174 0-.345.017-.511.044a3.14 3.14 0 00-1.236.48c-.005-.145-.011-.289-.011-.434 0-6.25 4.847-11.334 10.805-11.334 5.958 0 10.805 5.085 10.805 11.334 0 .145-.005.29-.01.433a3.163 3.163 0 00-1.748-.523h-.34v12.137h.34a3.197 3.197 0 002.939-1.953l2.033-.835v-6.56l-1.413-.58v-.001zM35.71 49.806a.498.498 0 100 .997.498.498 0 000-.997zM30.235 50.8a.498.498 0 100-.996.498.498 0 000 .997zM28.059 48.218a.498.498 0 100 .997.498.498 0 000-.997zM32.104 50.072a.498.498 0 100-.997.498.498 0 000 .997zM33.105 47.731a.498.498 0 100 .997.498.498 0 000-.997zM29.675 48.09a.498.498 0 10.996 0 .498.498 0 00-.996 0zM35.71 48.156a.498.498 0 10-.997 0 .498.498 0 00.997 0zM37.508 49.085a.498.498 0 100 .996.498.498 0 000-.996zM39 47.336a.498.498 0 100 .996.498.498 0 000-.996zM39.159 45.754a.498.498 0 100 .996.498.498 0 000-.996zM40.74 46.07a.498.498 0 100 .997.498.498 0 000-.997zM40.266 44.33a.498.498 0 100 .997.498.498 0 000-.997zM34.47 49.983a.498.498 0 10-.996 0 .498.498 0 00.997 0zM27.746 51.075a.498.498 0 100-.997.498.498 0 000 .997zM29.736 51.668a.498.498 0 100 .996.498.498 0 000-.996zM32.375 52.8a.498.498 0 100-.997.498.498 0 000 .997zM48.894 42.2a.498.498 0 100 .997.498.498 0 000-.997zM50.794 25.623a.497.497 0 10.7.082.497.497 0 00-.7-.082zM50.32 27.679a.497.497 0 10.7.082.497.497 0 00-.7-.082zM48.52 25.229a.497.497 0 10.78-.614.497.497 0 00-.78.614zM48.809 20.633a.498.498 0 10.616.781.498.498 0 00-.616-.781zM52.468 24.48a.497.497 0 10.78-.614.497.497 0 00-.78.615zM54.84 24.769a.498.498 0 10.617.781.498.498 0 00-.616-.781zM55.338 27.141a.497.497 0 10.782-.617.497.497 0 10-.782.617zM53.817 27.018a.497.497 0 10-.781.614.497.497 0 00.781-.614zM57.145 29.216a.498.498 0 10-.616-.781.498.498 0 00.616.781zM55.064 23.779a.498.498 0 10-.617-.782.498.498 0 00.617.782zM40.054 13.142a.498.498 0 10-.617-.781.498.498 0 00.617.781zM53.735 21.578a.498.498 0 10-.616-.78.498.498 0 00.616.78zM55.85 31.981a.497.497 0 10-.78.614.497.497 0 00.78-.614zM54.84 33.58a.498.498 0 10.617.781.498.498 0 00-.616-.78zM56.316 35.18a.497.497 0 10.617.784.497.497 0 00-.617-.783zM55.966 37.762a.498.498 0 10.616.781.498.498 0 00-.616-.781zM56.498 33.18a.498.498 0 10.617.781.498.498 0 00-.617-.781zM53.13 41.909a.498.498 0 10.617.78.498.498 0 00-.617-.78zM42.078 49.183a.498.498 0 10.617.781.498.498 0 00-.617-.781zM40.255 50.41a.498.498 0 10.616.782.498.498 0 00-.616-.782zM36.42 51.49a.498.498 0 10.618.782.498.498 0 00-.617-.782zM33.851 51.728a.498.498 0 10.617.78.498.498 0 00-.617-.78zM38.312 50.842a.498.498 0 10.616.781.498.498 0 00-.616-.78zM50.653 43.918a.498.498 0 10-.617-.78.498.498 0 00.617.78zM50.393 44.936a.498.498 0 10.616.782.498.498 0 00-.616-.782zM57.489 31.298a.497.497 0 10-.782.617.497.497 0 10.782-.617zM51.652 19.689a.497.497 0 10-.617-.784.497.497 0 00.617.784zM51.154 21.688a.498.498 0 10-.616-.782.498.498 0 00.616.782zM48.69 19.641a.497.497 0 10.781-.614.497.497 0 00-.781.614zM48.465 17.63a.498.498 0 10-.617-.782.498.498 0 00.617.781zM46.498 16.596a.5.5 0 00.554-.435.5.5 0 00-.99-.118.5.5 0 00.436.553zM46.244 18.243a.5.5 0 00.435.554.5.5 0 00.554-.436.5.5 0 00-.435-.553.5.5 0 00-.554.435zM45.325 15.307a.5.5 0 00.554-.435.5.5 0 00-.989-.118.5.5 0 00.435.553zM42.096 13.917a.5.5 0 00.554-.435.5.5 0 00-.435-.553.5.5 0 00-.554.434.5.5 0 00.435.554zM49.606 18.61a.5.5 0 00.554-.435.5.5 0 00-.989-.119.5.5 0 00.435.554zM45.478 17.63a.498.498 0 10-.616-.782.498.498 0 00.616.781zM43.392 17.311a.497.497 0 10-.782.617.497.497 0 10.782-.617zM54.34 36.596a.498.498 0 10.781-.618.498.498 0 00-.782.618zM53.384 36.69a.498.498 0 10-.617-.782.498.498 0 00.617.782zM51.95 37.01a.497.497 0 10-.7-.082c.172.217.483.253.7.083zM53.176 31.27a.498.498 0 10.616.782.498.498 0 00-.616-.781zM54.792 30.407a.498.498 0 10.616.782.498.498 0 00-.616-.782zM52.13 32.454a.498.498 0 10.617.781.498.498 0 00-.617-.781zM53.656 35.098a.498.498 0 10-.616-.781.498.498 0 00.616.781zM53.384 30.417a.498.498 0 10-.617-.782.498.498 0 00.617.782zM54.654 28.826a.498.498 0 10-.616-.782.498.498 0 00.616.782zM51.187 31.662a.497.497 0 10-.781.616.497.497 0 10.781-.616zM48.774 26.268a.497.497 0 10.7.082.497.497 0 00-.7-.082zM49.475 29.322a.498.498 0 10-.617-.781.498.498 0 00.617.781zM49.974 33.465a.498.498 0 10-.617-.782.498.498 0 00.617.782zM50.242 35.438a.498.498 0 10-.616-.78.498.498 0 00.616.78zM48.915 34.097a.497.497 0 10-.662.742.497.497 0 00.662-.742zM47.957 35.54a.497.497 0 10-.662.743.497.497 0 10.662-.743zM47.582 37.525a.497.497 0 10-.662.743.497.497 0 10.662-.743zM51.792 34.599a.498.498 0 10-.617-.782.498.498 0 00.617.782zM49.54 29.909a.498.498 0 10.617.781.498.498 0 00-.617-.781zM52.032 28.215a.498.498 0 10.617.78.498.498 0 00-.617-.78zM53.158 26.426a.497.497 0 10-.7-.082c.171.217.483.253.7.082zM48.578 32.179a.498.498 0 10-.617-.782.498.498 0 00.617.782zM50.89 30.403a.5.5 0 00.988.118.5.5 0 00-.989-.118zM46.624 25.265a.498.498 0 10.617.78.498.498 0 00-.617-.78z" fill="#000"></path><path d="M45.827 31.83a.497.497 0 10.7.082.497.497 0 00-.7-.083zM47.58 33.16a.497.497 0 10-.781.613.497.497 0 00.781-.614zM47.74 27.738a.498.498 0 10-.616-.782.498.498 0 00.616.782zM47.95 30.243a.5.5 0 00-.99-.119.5.5 0 00.99.119zM46.367 30.243a.5.5 0 00-.99-.119.5.5 0 00.99.119zM46.683 28.345a.5.5 0 00-.99-.119.5.5 0 00.99.119zM45.734 26.921a.5.5 0 00-.99-.118.5.5 0 00.99.118zM51.545 23.233a.497.497 0 10.781-.614.497.497 0 00-.781.614zM6.538 28.26a.499.499 0 10.51-.853.499.499 0 00-.51.852zM7.67 26.127a.499.499 0 10.51-.854.499.499 0 00-.51.854zM22.566 14.925a.499.499 0 10.51-.853.499.499 0 00-.51.853zM14.93 46.545a.499.499 0 10-.51.854.499.499 0 00.51-.854zM14.43 45.648a.499.499 0 10-.856-.512.499.499 0 00.856.512zM8.545 24.343a.499.499 0 10.51-.853.499.499 0 00-.51.853zM9.538 22.678a.5.5 0 10.51-.853.5.5 0 00-.51.853zM8.556 29.822a.499.499 0 10-.856-.512.499.499 0 00.856.512zM17.15 16.267a.498.498 0 10-.616-.781.498.498 0 00.616.781zM6.896 33.144a.498.498 0 10-.616-.782.498.498 0 00.616.782zM9.125 33.325a.498.498 0 10-.616-.781.498.498 0 00.616.781zM7.207 34.31a.498.498 0 10-.782.617.498.498 0 00.782-.618zM15.916 46.436a.498.498 0 100-.997.498.498 0 000 .997zM16.595 48.48a.498.498 0 100-.996.498.498 0 000 .997zM18.442 49.436a.498.498 0 100-.997.498.498 0 000 .997zM13.869 18.485a.498.498 0 100-.997.498.498 0 000 .997zM18.393 15.409a.498.498 0 100-.997.498.498 0 000 .997zM21.04 14.363a.497.497 0 10-.701-.704.497.497 0 00.702.704zM25.524 12.75a.497.497 0 10-.702-.704.497.497 0 00.702.704zM28.182 12.285a.497.497 0 10-.702-.704.497.497 0 00.702.704zM18.673 47.005a.498.498 0 10-.997 0 .498.498 0 00.997 0zM12.707 42.075a.498.498 0 10-.001.997.498.498 0 000-.997zM12.512 39.8a.498.498 0 10-.07-.993.498.498 0 00.07.994zM10.954 40.65a.498.498 0 100-.997.498.498 0 000 .997zM11.492 41.112a.498.498 0 100 .996.498.498 0 000-.996zM9.543 41.143a.498.498 0 100 .997.498.498 0 000-.997zM14.316 40.844a.498.498 0 10-.996 0 .498.498 0 00.996 0zM13.704 38.478a.498.498 0 100-.996.498.498 0 000 .996zM15.03 36.2a.498.498 0 10-.997 0 .498.498 0 00.997 0zM14.652 33.933a.498.498 0 100-.997.498.498 0 000 .997zM11.635 35.752a.498.498 0 100-.997.498.498 0 000 .997zM12.41 33.66a.498.498 0 100-.996.498.498 0 000 .997zM8.618 37.754a.498.498 0 10-.996 0 .498.498 0 00.996 0zM8.329 39.347a.498.498 0 100 .996.498.498 0 000-.996zM11.083 38.577a.498.498 0 10-.997 0 .498.498 0 00.997 0zM10.124 37.434a.498.498 0 100-.996.498.498 0 000 .996zM7.317 36.843a.498.498 0 100-.997.498.498 0 000 .997zM12.525 37.447a.497.497 0 10-.702-.704.497.497 0 00.702.704zM12.242 29.982a.498.498 0 100 .996.498.498 0 000-.996zM9.54 35.253a.498.498 0 10-.997 0 .498.498 0 00.997 0zM11.192 33.647a.498.498 0 10-.996 0 .498.498 0 00.996 0zM15.171 28.82a.498.498 0 100-.997.498.498 0 000 .996zM17.296 28.661a.498.498 0 100-.997.498.498 0 000 .997zM16.7 29.59a.498.498 0 10-.997 0 .498.498 0 00.996 0zM18.282 30.064a.498.498 0 10-.996 0 .498.498 0 00.996 0zM19.386 21.03a.498.498 0 100 .996.498.498 0 000-.996zM17.714 32.372a.498.498 0 100-.997.498.498 0 000 .997zM16.665 33.488a.498.498 0 100-.996.498.498 0 000 .996zM16.225 35.07a.498.498 0 100-.997.498.498 0 000 .997zM16.665 36.63a.498.498 0 100-.997.498.498 0 000 .996zM11.908 25.748a.498.498 0 100-.997.498.498 0 000 .997zM15.123 21.001a.498.498 0 100 .997.498.498 0 000-.997zM15.047 20.157a.498.498 0 100-.997.498.498 0 000 .997zM16.58 18.614a.498.498 0 100-.996.498.498 0 000 .997zM15.621 17.62a.498.498 0 10.001-.997.498.498 0 000 .997zM13.37 20.775a.498.498 0 100-.997.498.498 0 000 .997zM11.91 20.248a.498.498 0 10.001-.996.498.498 0 000 .996zM11.35 21.843a.498.498 0 100-.997.498.498 0 000 .997zM14.343 26.426a.498.498 0 100-.996.498.498 0 000 .996zM13.206 25.16a.498.498 0 100-.997.498.498 0 000 .996zM11.76 27.034a.498.498 0 10.997 0 .498.498 0 00-.996 0zM9.499 25.113a.498.498 0 10.997 0 .498.498 0 00-.997 0zM13.357 22.923a.498.498 0 10-.07-.994.498.498 0 00.07.994zM11.248 23.943a.498.498 0 100-.997.498.498 0 000 .997zM9.829 30.444a.498.498 0 100-.997.498.498 0 000 .997zM6.477 30.706a.498.498 0 100-.996.498.498 0 000 .996zM40.136 14a.5.5 0 10.857.513.5.5 0 00-.857-.512zM39.218 15.744a.499.499 0 10.51-.853.499.499 0 00-.51.853zM39.038 17.507a.499.499 0 10.51-.853.499.499 0 00-.51.853zM37.456 17.982a.499.499 0 10.51-.853.499.499 0 00-.51.853zM41.253 15.885a.499.499 0 10.51-.854.499.499 0 00-.51.854zM41.353 17.536a.499.499 0 10-.857-.512.499.499 0 00.857.512zM8.566 31.717a.498.498 0 100-.997.498.498 0 000 .997zM9.944 31.593a.498.498 0 10.997 0 .498.498 0 00-.997 0zM11.185 29.07a.498.498 0 10.996 0 .498.498 0 00-.996 0zM8.995 27.706a.498.498 0 100-.997.498.498 0 000 .997zM10.51 28.41a.498.498 0 100-.997.498.498 0 000 .997zM13.48 29.227a.498.498 0 10.001-.996.498.498 0 000 .996zM15.417 32.092a.498.498 0 100-.997.498.498 0 000 .997zM13.704 32.215a.498.498 0 100-.997.498.498 0 000 .997zM14.501 30.37a.498.498 0 100-.997.498.498 0 000 .996zM44.77 48.378a.498.498 0 00-.518.85.498.498 0 00.518-.85zM44.012 45.958a.499.499 0 00.517-.85.498.498 0 00-.517.85zM42.917 46.809a.498.498 0 10-.851-.517.498.498 0 00.851.517zM46.904 44.45a.498.498 0 10.516-.849.498.498 0 00-.517.85zM46.057 44.471a.498.498 0 10-.852-.516.498.498 0 00.852.516zM44.79 43.206a.498.498 0 10-.851-.517.498.498 0 00.851.517zM46.407 46.65a.498.498 0 10-.852-.516.498.498 0 00.852.517zM44.657 47.563a.498.498 0 10-.852-.516.498.498 0 00.852.516zM46.963 47.375a.498.498 0 00-.517.85.498.498 0 00.517-.85zM39.595 48.876a.498.498 0 00-.518.85.498.498 0 00.518-.85zM41.32 47.967a.498.498 0 00-.517.849.498.498 0 00.517-.85zM36.547 47.83a.498.498 0 10.851.517.498.498 0 00-.851-.516zM33.264 45.833a.498.498 0 100 .997.498.498 0 000-.997zM35.394 45.468a.498.498 0 10-.997 0 .498.498 0 00.997 0zM36.23 46.249a.498.498 0 10.852.517.498.498 0 00-.852-.517zM37.813 44.351a.498.498 0 10.852.517.498.498 0 00-.852-.517zM47.713 45.044a.498.498 0 00-.517.85.498.498 0 00.517-.85zM49.34 44.473a.499.499 0 00-.518.85.498.498 0 00.518-.85zM48.94 46.502a.498.498 0 10-.516.849.498.498 0 00.516-.849zM50.182 41.493a.498.498 0 10.347.933.498.498 0 00-.347-.933zM49.576 40.558a.498.498 0 10-.934.348.498.498 0 00.934-.348zM46.79 42.667a.498.498 0 10-.346-.933.498.498 0 00.347.933zM47.899 39.962a.498.498 0 10-.933.348.498.498 0 00.933-.348zM51.826 41.47a.497.497 0 10-.346-.932.497.497 0 00.346.933zM49.417 38.224a.498.498 0 10-.933.347.498.498 0 00.933-.347zM50.899 38.714a.498.498 0 10-.933.348.498.498 0 00.933-.348zM49.917 36.489a.498.498 0 10-.934.348.498.498 0 00.934-.348zM51.808 37.923a.498.498 0 10.347.933.498.498 0 00-.347-.933zM25.17 15.247a.498.498 0 100-.996.498.498 0 000 .996zM25.17 16.549a.498.498 0 10.998 0 .498.498 0 00-.997 0zM41.896 19.856a.498.498 0 10-.996 0 .498.498 0 00.996 0zM43.262 18.78a.498.498 0 100 .996.498.498 0 000-.997zM52.1 43.393a.498.498 0 10-.414.906.498.498 0 00.414-.906zM54.618 40.212a.496.496 0 00-.494.501.496.496 0 00.502.494.496.496 0 00.494-.502.496.496 0 00-.502-.493zM54.758 37.561a.496.496 0 00-.493.501.496.496 0 00.501.494.496.496 0 00.494-.502.496.496 0 00-.502-.493zM53.63 39.454a.496.496 0 00-.502-.493.497.497 0 10.502.494zM15.092 23.477a.498.498 0 10.347.932.498.498 0 00-.347-.932zM16.58 20.122a.498.498 0 10.996 0 .498.498 0 00-.997 0zM15.584 26.195a.498.498 0 10.997 0 .498.498 0 00-.997 0zM18.37 27.473a.498.498 0 100-.996.498.498 0 000 .996zM17.454 22.898a.498.498 0 100 .996.498.498 0 000-.996zM17.454 24.796a.498.498 0 100 .996.498.498 0 000-.996zM19.924 19.307a.498.498 0 100 .997.498.498 0 000-.997zM18.988 23.441a.498.498 0 10-.07-.994.498.498 0 00.07.994zM16.878 21.428a.498.498 0 100 .997.498.498 0 000-.997zM30.591 13.057a.497.497 0 10.346.932.497.497 0 00-.346-.932zM30.323 15.714a.498.498 0 10-.346-.933.498.498 0 00.346.933zM32.607 12.294a.498.498 0 100-.996.498.498 0 000 .996zM27.075 16.225a.498.498 0 10.933-.348.498.498 0 00-.933.348zM32.284 16.261a.498.498 0 10-.347-.933.498.498 0 00.347.933zM36.416 13.586a.499.499 0 10-.71-.699.499.499 0 00.71.7zM37.33 12.522a.499.499 0 10-.712-.7.499.499 0 00.712.7zM35.19 12.328a.499.499 0 10-.71-.7.499.499 0 00.71.7zM35.425 16.1a.499.499 0 10.697-.709.499.499 0 00-.697.709zM37.708 15.619a.499.499 0 10-.712-.7.499.499 0 00.712.7zM37.516 14.336a.499.499 0 10.697-.708.499.499 0 00-.697.708zM32.283 13.41a.499.499 0 10.711.7.499.499 0 00-.711-.7zM43.28 15.606a.499.499 0 10.71.7.499.499 0 00-.71-.7zM43.688 14.83a.499.499 0 10-.711-.7.499.499 0 00.71.7zM34.645 14.847a.499.499 0 10-.711-.699.499.499 0 00.711.7zM22.876 13.54a.499.499 0 10.51-.854.499.499 0 00-.51.855zM26.427 13.996a.499.499 0 10.51-.853.499.499 0 00-.51.853zM28.11 13.745a.499.499 0 10.857.511.499.499 0 00-.856-.511zM30.125 12.127a.499.499 0 10.51-.853.499.499 0 00-.51.853zM19.727 46.404a.498.498 0 10.139-.688.497.497 0 00-.14.69v-.002zM21.264 16.28a.498.498 0 10.584-.807.498.498 0 00-.584.807zM23.283 17.712a.497.497 0 10-.806-.584.497.497 0 00.806.584zM21.883 20.704a.497.497 0 10-.806-.584.497.497 0 00.806.584zM22.367 18.346a.498.498 0 10-.584.806.498.498 0 00.584-.806zM23.632 19.295a.498.498 0 10-.583.806.498.498 0 00.583-.806zM21.258 21.825a.498.498 0 10-.583.807.498.498 0 00.583-.807zM19.194 44.97a.498.498 0 10-.984-.156.498.498 0 00.984.155zM17.093 44.084a.498.498 0 10-.156.983.498.498 0 00.156-.983zM18.877 43.184a.498.498 0 10.156-.983.498.498 0 00-.156.983zM19.72 47.355a.498.498 0 10-.156.983.498.498 0 00.156-.983zM13.898 44.147a.498.498 0 10.156-.983.498.498 0 00-.156.983zM11.166 43.092a.498.498 0 10-.156.983.498.498 0 00.156-.983zM12.732 44.693a.497.497 0 10-.643.758.497.497 0 00.643-.758zM25.903 49.082a.498.498 0 10-.156.983.498.498 0 00.156-.983zM25.294 48.085a.497.497 0 10.983.156.497.497 0 00-.983-.156zM24.187 46.662a.498.498 0 10.983.155.498.498 0 00-.983-.155zM25.294 45.397a.498.498 0 10.983.155.498.498 0 00-.983-.155zM26.56 43.657a.498.498 0 10.983.155.498.498 0 00-.983-.155zM26.718 47.136a.498.498 0 10.983.156.498.498 0 00-.983-.156zM27.826 45.397a.498.498 0 10.983.155.498.498 0 00-.983-.155zM29.567 46.187a.497.497 0 10.982.156.497.497 0 00-.982-.156zM31.308 45.238a.498.498 0 10.983.156.498.498 0 00-.983-.156zM31.308 47.294a.498.498 0 10.983.156.498.498 0 00-.983-.156zM26.826 51.355a.498.498 0 10-.156.983.498.498 0 00.156-.983zM30.548 44.587a.498.498 0 10-.997 0 .498.498 0 00.997 0zM29.282 42.847a.498.498 0 10-.996 0 .498.498 0 00.996 0zM29.575 38.505a.498.498 0 100-.996.498.498 0 000 .996zM31.662 35.834a.498.498 0 10-.997 0 .498.498 0 00.997 0zM30.306 40.375a.498.498 0 100-.997.498.498 0 000 .997zM32.148 40.878a.498.498 0 10-.996 0 .498.498 0 00.996 0zM31.79 37.449a.498.498 0 100 .996.498.498 0 000-.996zM31.722 43.48a.498.498 0 100-.997.498.498 0 000 .997zM30.529 42.559a.498.498 0 100-.996.498.498 0 000 .996zM29.302 36.017a.498.498 0 100-.996.498.498 0 000 .996zM28.369 37.669a.498.498 0 10-.997 0 .498.498 0 00.997 0zM28.526 40.805a.498.498 0 100-.997.498.498 0 000 .997zM26.943 39.856a.498.498 0 100-.997.498.498 0 000 .997zM27.832 41.465a.497.497 0 10-.782.616.497.497 0 10.782-.617zM34.047 41.036a.498.498 0 10-.997 0 .498.498 0 00.997 0zM34.413 43.321a.498.498 0 100-.996.498.498 0 000 .996zM33.305 44.903a.498.498 0 100-.997.498.498 0 000 .997zM36.224 34.494a.498.498 0 10-.156.983.498.498 0 00.156-.983zM32.743 34.494a.498.498 0 10-.156.983.498.498 0 00.156-.983zM34.484 35.601a.498.498 0 10-.156.984.498.498 0 00.156-.984zM33.692 37.341a.498.498 0 10-.156.984.498.498 0 00.156-.984zM34.642 39.081a.498.498 0 10-.156.983.498.498 0 00.156-.983zM32.585 39.081a.498.498 0 10-.156.983.498.498 0 00.156-.983zM27.256 36.342a.498.498 0 10-.983-.156.498.498 0 00.983.156zM27.732 34.76a.498.498 0 10-.983-.156.498.498 0 00.983.156zM24.091 50.586a.497.497 0 10.2.974.497.497 0 00-.2-.974zM18.644 19.065a.498.498 0 100-.996.498.498 0 000 .996zM20.551 18.461a.498.498 0 100-.996.498.498 0 000 .996zM23.87 48.901a.498.498 0 10-.993.073.498.498 0 00.993-.073zM22.269 50.1a.498.498 0 10.072.994.498.498 0 00-.072-.994zM20.79 49.487a.498.498 0 10.072.993.498.498 0 00-.072-.993zM22.41 47.385a.498.498 0 10.994-.073.498.498 0 00-.993.073zM21.18 47.61a.498.498 0 10.072.994.498.498 0 00-.072-.993zM18.676 16.562a.498.498 0 10.934-.348.498.498 0 00-.934.348zM14.854 39.586a.498.498 0 100-.997.498.498 0 000 .997zM15.8 43.505a.498.498 0 10-.072-.993.498.498 0 00.072.993zM17.084 40.175a.498.498 0 10-.991-.098.498.498 0 00.991.098zM16.189 38.41a.498.498 0 100-.996.498.498 0 000 .996zM15.417 41.84a.498.498 0 100-.996.498.498 0 000 .997zM17.218 42.632a.498.498 0 100-.997.498.498 0 000 .997zM13.37 35.253a.498.498 0 100-.996.498.498 0 000 .996zM49.084 22.632a.498.498 0 10.617.781.498.498 0 00-.617-.781zM50.237 24.878a.497.497 0 10.782-.614.497.497 0 00-.782.614zM45.455 19.456a.498.498 0 10-.616-.781.498.498 0 00.616.781zM47.968 22.41a.498.498 0 10-.616-.78.498.498 0 00.616.78zM44.428 24.595a.498.498 0 10.616.781.498.498 0 00-.616-.781zM46.643 19.785a.498.498 0 10.616.781.498.498 0 00-.616-.781zM43.84 20.982a.497.497 0 10.781-.617.497.497 0 10-.781.617zM45.445 23.155a.498.498 0 10.617.782.498.498 0 00-.617-.782zM47.057 24.12a.497.497 0 10.781-.614.497.497 0 00-.781.614zM45.431 22.146a.497.497 0 10.782-.617.497.497 0 10-.782.617zM23.47 16.052a.498.498 0 10.997 0 .498.498 0 00-.996 0z" fill="#000"></path><path d="M32 9.223C16.56 9.223 4 19.44 4 32s12.56 22.777 28 22.777c15.438 0 27.998-10.217 27.998-22.777S47.438 9.223 32 9.223zm0 45.268C16.718 54.49 4.285 44.4 4.285 32 4.286 19.598 16.72 9.51 32 9.51c15.28 0 27.713 10.088 27.713 22.49S47.28 54.49 31.999 54.49z" fill="#000"></path><path d="M20.474 43.53c-.633 0-.633.982 0 .982s.633-.982 0-.982zM22.063 44.815c-.633 0-.633.982 0 .982s.633-.982 0-.982zM23.804 44.34c-.633 0-.633.982 0 .982s.633-.982 0-.982zM19.265 25.229c.633 0 .633-.982 0-.982s-.633.982 0 .982zM26.64 18.624c.634 0 .634-.982 0-.982-.632 0-.632.982 0 .982zM24.925 18.14c-.633 0-.633.982 0 .982s.633-.982 0-.982zM29.206 16.432c-.633 0-.633.982 0 .982s.633-.982 0-.982zM31.105 16.432c-.633 0-.633.982 0 .982s.633-.982 0-.982zM34.036 17.08c.633 0 .633-.982 0-.982s-.633.982 0 .982zM42.333 21.879c.633 0 .633-.982 0-.982s-.633.982 0 .982zM39.453 18.273c-.633 0-.633.982 0 .982s.633-.982 0-.982zM35.813 17.008c-.633 0-.633.982 0 .982s.633-.982 0-.982zM43.673 23.527c.633 0 .633-.982 0-.982s-.633.982 0 .982zM42.463 44.949c.633 0 .633-.982 0-.982s-.633.982 0 .982zM36.468 38.162a.498.498 0 100 .997.498.498 0 000-.997zM36.943 39.586a.498.498 0 100 .996.498.498 0 000-.996zM37.22 43.013a.498.498 0 10-.851-.517.498.498 0 00.851.517zM36.745 44.595a.498.498 0 10-.851-.517.498.498 0 00.851.517zM35.123 37.075a.498.498 0 10.851.517.498.498 0 00-.85-.517zM36.547 36.443a.498.498 0 10.851.516.498.498 0 00-.851-.516zM35.342 41.944c.633 0 .633-.983 0-.983s-.633.983 0 .983zM25.778 28.582a.498.498 0 10-.156.983.498.498 0 00.156-.983zM25.462 26.684a.498.498 0 10-.156.983.498.498 0 00.156-.983zM27.222 28.14a.498.498 0 100-.997.498.498 0 000 .996zM24.373 25.925a.498.498 0 100-.997.498.498 0 000 .997zM22.79 30.037a.498.498 0 100-.997.498.498 0 000 .997zM24.215 30.512a.498.498 0 100-.997.498.498 0 000 .997zM23.581 28.297a.498.498 0 10.001-.996.498.498 0 000 .996zM28.171 26.083a.498.498 0 100-.997.498.498 0 000 .997zM33.013 27.19a.498.498 0 100-.996.498.498 0 000 .996zM35.188 28.462a.498.498 0 100-.997.498.498 0 000 .997zM31.143 27.603a.498.498 0 100-.997.498.498 0 000 .997zM30.141 28.947a.498.498 0 100-.996.498.498 0 000 .996zM33.572 28.59a.498.498 0 10-.996 0 .498.498 0 00.996 0zM27.855 29.47a.498.498 0 10.996 0 .498.498 0 00-.996 0zM28.459 27.33a.498.498 0 10.997 0 .498.498 0 00-.997 0zM35.501 26.602a.498.498 0 100-.997.498.498 0 000 .997zM33.827 25.487a.498.498 0 100-.997.498.498 0 000 .997zM30.712 25.825a.498.498 0 100-.996.498.498 0 000 .996zM29.554 24.634a.498.498 0 10-.617-.78.498.498 0 00.617.78zM29.983 30.845a.498.498 0 100-.996.498.498 0 000 .996zM27.696 31.21a.498.498 0 10.997 0 .498.498 0 00-.997 0zM26.114 30.736a.498.498 0 10.997 0 .498.498 0 00-.997 0zM36.212 32.864a.497.497 0 10-.982-.156.497.497 0 00.982.156zM37.794 33.654a.498.498 0 10-.983-.155.498.498 0 00.983.155zM36.054 29.7a.497.497 0 10-.983-.156.497.497 0 00.983.156zM35.42 31.282a.498.498 0 10-.983-.156.498.498 0 00.983.156zM37.478 31.44a.498.498 0 10-.983-.155.498.498 0 00.983.155zM33.68 30.491a.498.498 0 10-.983-.156.498.498 0 00.983.156zM31.939 31.44a.498.498 0 10-.983-.156.498.498 0 00.983.156zM31.939 29.384a.498.498 0 10-.983-.156.498.498 0 00.983.156zM36.42 25.324a.498.498 0 10.157-.983.498.498 0 00-.156.983zM33.32 22.1a.498.498 0 10.001-.996.498.498 0 000 .997zM31.234 22.195a.498.498 0 10.997 0 .498.498 0 00-.997 0zM29.84 23.27a.498.498 0 100-.997.498.498 0 000 .996zM28.256 22.479a.498.498 0 100-.997.498.498 0 000 .997zM27.465 24.06a.498.498 0 100-.997.498.498 0 000 .997zM25.725 24.218a.498.498 0 100-.996.498.498 0 000 .996zM26.516 25.958a.498.498 0 100-.997.498.498 0 000 .997zM33.436 23.64a.498.498 0 100-.997.498.498 0 000 .996zM35.951 22.891a.498.498 0 10.997 0 .498.498 0 00-.997 0zM34.685 21.784a.498.498 0 10.996 0 .498.498 0 00-.996 0zM31.577 24.483a.498.498 0 10.156-.984.498.498 0 00-.156.984zM30.31 21.794a.498.498 0 10.156-.984.498.498 0 00-.156.984zM37.907 24.483a.498.498 0 10.156-.984.498.498 0 00-.156.984zM34.69 23.586a.498.498 0 10.983.155.498.498 0 00-.983-.155zM32.858 33.265a.498.498 0 10-.996 0 .498.498 0 00.996 0zM31.434 33.74a.498.498 0 10-.996 0 .498.498 0 00.997 0zM28.48 34.175a.498.498 0 00.517-.85.498.498 0 00-.517.85zM26.58 33.384a.498.498 0 00.518-.85.498.498 0 00-.517.85zM33.945 31.92a.498.498 0 00-.517.85.498.498 0 00.517-.85zM34.578 33.344a.498.498 0 00-.517.85.498.498 0 00.517-.85zM41.224 30.097a.5.5 0 10-.59-.805.5.5 0 00.59.805zM39.008 28.357a.5.5 0 10-.59-.805.5.5 0 00.59.805zM40.674 28.579a.5.5 0 10-.59-.806.5.5 0 00.59.806zM40.32 26.947a.5.5 0 10-.59-.806.5.5 0 00.59.806zM37.943 26.547a.5.5 0 00-.587-.806.5.5 0 00.587.806zM39.24 25.726a.5.5 0 10-.59-.806.5.5 0 00.59.806zM37.302 28.013a.497.497 0 10-.702-.704.497.497 0 00.702.704zM39.813 29.885a.497.497 0 10-.966.235.497.497 0 00.966-.235zM38.303 29.757a.497.497 0 10-.966.235.497.497 0 00.966-.235zM29.075 32.14c0 .632.983.632.983 0 0-.634-.983-.634-.983 0z" fill="#000"></path></svg><span>Listen to Podcasts and Articles</span></a></li></ul></div><div class="ExpandedNav_print__7d4vw" data-event-element="print edition"><h2 class="ExpandedNav_title__C8QcN ExpandedNav_printTitle__PKCL7">The Print Edition</h2><div class="ExpandedNav_printContainer__Lp_nj"><a href="/magazine/" class="ExpandedNav_printImgLink__gcbdt"><img alt="View the current print edition" loading="lazy" class="Image_root__XxsOp Image_lazy__hYWHV ExpandedNav_printImg__hHeRU" src="https://www.theatlantic.com/magazine/images/current-issue.420.jpg" width="266" height="200"/></a><div class="ExpandedNav_printLinks__gNywy"><div class="ExpandedNav_topPrintLinks__UytSB"><a href="/magazine/" class="ExpandedNav_latestIssue__iDXQm">Latest Issue</a><a href="/magazine/backissues/" class="ExpandedNav_pastIssues__nkE14">Past Issues</a></div><hr class="ExpandedNav_hr__5T2Ez"/><a href="https://accounts.theatlantic.com/products/gift" class="ExpandedNav_giveAGift__vyp0c">Give a Gift</a></div></div></div></div></div></div></li><li class="Nav_navListItem__l2afO Nav_hideOnTablet__wyFPd Nav_searchLi__yxgD4"><button class="NavSearchButton_root__DcP_y" aria-label="Search The Atlantic" aria-expanded="false" aria-controls="nav-desktop-search" data-event-element="search icon" data-event-verb="opened" data-event-surface="search" data-event-module="search overlay"><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16" class="NavSearchButton_searchIcon__Acpm1"><path d="M15.85 15.15l-5.27-5.28a6 6 0 10-.71.71l5.28 5.27a.48.48 0 00.7 0 .48.48 0 000-.7zM1 6a5 5 0 115 5 5 5 0 01-5-5z"></path></svg></button><div data-event-surface="search" data-event-module="search overlay" class="SearchOverlay_root__lmUcH" hidden="" id="nav-desktop-search"><div data-focus-guard="true" tabindex="0" style="width:1px;height:0px;padding:0;overflow:hidden;position:fixed;top:1px;left:1px"></div><div data-focus-lock-disabled="false" aria-modal="true" aria-labelledby="search-label" role="dialog"><form method="GET" action="/search/" class="SearchOverlay_searchForm___U0R_"><div class="SearchInput_root__6XLPB"><div class="VisuallyHidden_root__yoK4r"><label for="search-input-:R5pna5im:">Search The Atlantic</label></div><button type="submit" title="Submit" class="SearchInput_searchButton__u0CP0"><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16" aria-hidden="true" width="20"><path d="M15.85 15.15l-5.27-5.28a6 6 0 10-.71.71l5.28 5.27a.48.48 0 00.7 0 .48.48 0 000-.7zM1 6a5 5 0 115 5 5 5 0 01-5-5z"></path></svg></button><input type="search" name="q" id="search-input-:R5pna5im:" class="SearchInput_searchInput__5hWhI SearchInput_hideClear__re5AE" placeholder="Search The Atlantic..." autoComplete="off" required=""/></div><div class="QuickLinks_quickLinksContainer__F_iFd"><div class="QuickLinks_quickLinksHeading__ms7Ht">Quick Links</div><ul class="QuickLinks_quickLinksList__e7x66"><li class="QuickLinks_quickLinkListItem__59_09"><a class="QuickLinks_quickLink__w_Fp0" href="/audio" data-event-element="quick link" data-event-position="1"><img alt="" loading="lazy" class="Image_root__XxsOp Image_lazy__hYWHV QuickLinks_quickLinkImage__FTMBA" src="https://cdn.theatlantic.com/media/files/audio/intro_sprint_2_emblem.png" width="148" height="148"/><div class="QuickLinks_quickLinkLabel__TYtIC">Audio</div></a></li><li class="QuickLinks_quickLinkListItem__59_09"><a class="QuickLinks_quickLink__w_Fp0" href="/games/daily-crossword/" data-event-element="quick link" data-event-position="2"><img alt="" loading="lazy" class="Image_root__XxsOp Image_lazy__hYWHV QuickLinks_quickLinkImage__FTMBA" src="https://cdn.theatlantic.com/media/files/2025/crossword_icon_intro_sprint_2.png" width="148" height="148"/><div class="QuickLinks_quickLinkLabel__TYtIC">Crossword Puzzle</div></a></li><li class="QuickLinks_quickLinkListItem__59_09"><a class="QuickLinks_quickLink__w_Fp0" href="/archive/" data-event-element="quick link" data-event-position="3"><img alt="" loading="lazy" class="Image_root__XxsOp Image_lazy__hYWHV QuickLinks_quickLinkImage__FTMBA" src="https://cdn.theatlantic.com/media/files/archive-thumbnail.png" width="148" height="148"/><div class="QuickLinks_quickLinkLabel__TYtIC">Magazine Archive</div></a></li><li class="QuickLinks_quickLinkListItem__59_09"><a class="QuickLinks_quickLink__w_Fp0" href="https://accounts.theatlantic.com/accounts/subscription/" data-event-element="quick link" data-event-position="4"><img alt="" loading="lazy" class="Image_root__XxsOp Image_lazy__hYWHV QuickLinks_quickLinkImage__FTMBA" src="https://cdn.theatlantic.com/media/files/YourSubscription_300x300.jpg" width="148" height="148"/><div class="QuickLinks_quickLinkLabel__TYtIC">Your Subscription</div></a></li></ul></div><button type="button" aria-label="Close Search" class="SearchOverlay_closeButton___zntA" data-event-verb="closed" data-event-element="close icon"><svg viewBox="0 0 16 16" xmlns="http://www.w3.org/2000/svg" class="SearchOverlay_closeIcon__DrMMb"><path d="M9.525 8l6.159 6.159a1.078 1.078 0 11-1.525 1.525L8 9.524l-6.159 6.16a1.076 1.076 0 01-1.525 0 1.078 1.078 0 010-1.525L6.476 8 .315 1.841A1.078 1.078 0 111.841.316L8 6.476l6.16-6.16a1.078 1.078 0 111.524 1.525L9.524 8z" fill-rule="evenodd"></path></svg></button></form></div><div data-focus-guard="true" tabindex="0" style="width:1px;height:0px;padding:0;overflow:hidden;position:fixed;top:1px;left:1px"></div></div></li><li class="Nav_navListItem__l2afO Nav_hideOnTablet__wyFPd"><a class="Nav_navLink__34Bol" href="/most-popular/">Popular</a></li><li class="Nav_navListItem__l2afO Nav_hideOnTablet__wyFPd"><a class="Nav_navLink__34Bol" href="/latest/">Latest</a></li><li class="Nav_navListItem__l2afO Nav_hideOnTablet__wyFPd"><a class="Nav_navLink__34Bol" href="/newsletters/">Newsletters</a></li></ul><div aria-hidden="true" class="Nav_middleContainer__7JzLF" data-event-element="wordmark"><a href="/" class="Nav_hideAboveMobile__1lhmL Nav_mobileBigALink__eWXD_" tabindex="-1"><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 87.83 134" class="Nav_mobileBigA__9PTCs Nav_hideOnMobile__IESg8"><path d="M24.48 95.13c-.56 0-.74-.37-.74-.93l13.08-55.88c.19-.94.93-.94 1.12 0L50.09 94.2c0 .56-.19.93-.75.93zM48.22.19a22.54 22.54 0 01-7.66 5.05c-.75.19-.94.37-1.13 1.12l-26.72 112.5c-2 9-4.67 10.66-11.77 11.22a.88.88 0 00-.94.93v2.06a.88.88 0 00.92.93h25.6a.88.88 0 00.93-.93V131a.88.88 0 00-.93-.93c-9.53 0-10.47-2.81-8.6-10.66l4.49-19.25a1.18 1.18 0 011.12-.93h26.74a1.19 1.19 0 011.13.93l5 23.18c1.12 5-.75 6.17-7.1 6.73a.88.88 0 00-.93.93v2.06a.88.88 0 00.93.93h37.62a.88.88 0 00.94-.93V131a.88.88 0 00-.94-.93c-5.79-.56-8.22-1.5-9.34-6.73L49.34.57c-.19-.56-.75-.75-1.12-.38"></path></svg></a><a href="/" class="Nav_navLink__34Bol" tabindex="-1"><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 214 33.24" class="Nav_logo__RLN3C"><path d="M39.39 13.2c-2.4 0-4.43 1.82-7 5.32-1.18 1.64-2.7 4-3.37 5-.38.51-.68.43-.47-.12l1.78-4.56 6.36-17.5C37 .62 34.46-.25 34 .62v.09c-1.09 2.32-3.12 3.08-6.75 2.95S16.32 1.52 10.8 1.52C3.88 1.52 0 5.78 0 10.8c0 2.82 1.85 4.64 4.34 4.55a2.27 2.27 0 002.41-1.81 1.2 1.2 0 00-1.56-1.43c-2.45.51-3.29-1.18-3.29-2.49 0-3.12 2.66-5.44 8.22-5.44 1.43 0 4.22.34 7.17.67-3.75 11.3-7.55 21.77-8.48 24.25a2.07 2.07 0 01-1.35 1.44c-1.34.42-1.77.46-2.61.67-1.27.3-1.06 1.35-.17 1.31 1.6-.09 3.67-.3 5.31-.3 2 0 5.61.17 6.16.21 1 .09 1.14-1.14.3-1.26-.59-.09-1.56-.25-2.49-.38-1.1-.13-1.43-.59-1.18-1.48.55-1.47 7-20.11 8.27-24 2 .25 3.71.42 4.84.5 2.33.14 4.57 0 6.5-1.41l-5.1 14.4-4.47 12.33c-.76 2 2.1 2.15 2.74.93a81.64 81.64 0 017.63-12.36c1.86-2.7 3.59-4.31 4.81-4.31.93 0 1.47.51 1.47 1.65 0 1.52-.71 3.88-2.15 7.89-1.89 5.23-2.61 6.62-3.24 6.66s-1.86-1.52-2.53-1.69a1.39 1.39 0 00-1.65.72c-.34.59-.12 2.49 2.74 2.62 3.42.16 6.33-3.34 8.35-8.94 1.39-3.8 1.73-5.74 1.73-7.13 0-2.7-1.26-3.97-3.33-3.97zm57.9 18.09c-2.15-.5-3-1.3-3-2.15l.09-1.77c0-1.3 1-20.49 1.22-23.36.17-2.11-2.24-2-3.25-.76l-2 2.57C87.89 8.9 78 21.68 73.17 27.67A11.5 11.5 0 0168 31.25c-.8.21-.72 1.06.17 1.06.71 0 2.82-.25 4.38-.25s4.43.12 5.15.16 1-.76 0-1c-2-.59-3-1-3-1.52s.46-1.22 1.56-2.74c.84-1.18 2.86-3.84 5.1-6.79H91c-.21 4.05-.46 8.31-.5 9.15a1.14 1.14 0 01-.93 1.14l-2.15.63c-.59.17-.85 1.27.08 1.23 2.11-.13 3.88-.3 4.81-.3 1.39 0 3.75.3 4.85.34s.94-.85.13-1.07zm-6-15.47c0 .76-.09 1.6-.13 2.49h-8.25c3.84-5.07 7.89-10.38 8.23-10.89s.67-.25.63.13c-.13 1.86-.34 5.27-.5 8.27zM55.08 13.5c-3.67-.17-7.76 4.09-9.7 10.5-1.9 6.2.21 8.77 2.53 8.77 1.69 0 4.51-2.19 6.07-4.72.55-.89.13-1.82-.71-.89-1.06 1.14-2.49 2.36-4 2.07-1-.17-1.94-1.9-.46-6.2 3.54-.17 7.71-2.19 8.77-5.53.92-2.88-.98-3.96-2.5-4zm.38 3.12c-.89 2.61-4 4.8-6.24 5.35 2.15-5.69 4.21-7.21 5.52-7.17.72 0 1.06.82.72 1.82zm53.94-1h3.42c.76 0 1.14-.21 1.3-.76.3-.72.13-1.06-.63-1.06h-3.42l1.65-4.38c.21-.59 0-.89-.34-.89h-1.77c-.46 0-.63.13-.84.72L107 13.83h-2.7c-.38 0-.68-.08-.93 1.06-.09.55 0 .76.55.76h2.4l-4.09 10.67a45.64 45.64 0 00-1.69 4.68c-.25 1.48.64 2.07 1.73 1.86 2.15-.38 5.23-2.62 8-6.12.76-1 .13-1.64-.63-.84a34.4 34.4 0 01-3.67 3.16c-1.1.72-1.64.21-1.26-.84zm38.04-1c.25-.59-.59-.76-2.53-1.13-.59-.13-.93.5-1.94 2.61a4 4 0 00-3.5-1.43c-3.08.08-6.88 2.86-10 7.12-2.49 3.42-3.25 5.78-2.78 8.31a3.11 3.11 0 003.08 2.52c2.32.08 4.64-2.11 7-4.52l1.48-1.48c.42-.42.8-.17.54.34a23.77 23.77 0 00-1.89 4.17c-.3 1.48.5 1.86 1.64 1.69 2.19-.29 5.61-2.32 8.23-5.94.75-1.06 0-1.65-.68-.85a26.62 26.62 0 01-3.75 3.29c-1.14.76-1.65.55-1.31-.34.17-.55.8-2.07 6.41-14.36zm-9.74 11c-2.66 2.45-4.81 4.22-6.29 4.22-1 0-1.47-.43-1.56-1.14-.25-1.86 1.44-4.68 2.83-6.58 2.4-3.16 5.36-5.78 7.25-5.78 1.31 0 2 .55 2.11 1.35.25 1.46-2.19 5.93-4.34 7.87zm58.58-12.71c-2.07 0-4.85 1.47-7.47 4.38-.84 1-.21 1.65.59.93a20.28 20.28 0 012.87-2.19c.89-.55 1.48-.13 1.22.67-.21.64-.84 2.2-1.3 3.25l-2.87 6.58c-.8 1.86-1.56 3.71-1.73 4.22-.38 1.31.29 2 1.35 2 2 0 4.77-1.65 7.42-4.6.84-1 .21-1.64-.59-.93a28 28 0 01-3.12 2.4c-.88.54-1.52.12-1.22-.68.21-.59.84-1.94 1.26-2.91l2.91-6.58c.85-1.94 1.82-4 2-4.55.32-1.28-.31-1.99-1.32-1.99zm2.53-10.21a2.39 2.39 0 00-2.53 2.15 2.09 2.09 0 001.85 2.45 2.43 2.43 0 002.49-2.11 2.08 2.08 0 00-1.81-2.49zm11.68 10.84c-3.71-.17-7.68 4.13-9.62 10.46s.17 8.77 2.62 8.77c1.69 0 4.51-2 6.2-4.72.55-.89.13-1.82-.72-.89-1.05 1.14-2.4 2.19-3.79 2.11s-2.37-2-.76-6.62c2.36-6.66 4-7.42 4.72-7.47s2.19 1.86 3.08 2.07a1.36 1.36 0 001.64-.71c.38-.72.14-2.83-3.37-3zm-23.95.29h-3.42l1.64-4.38c.22-.59 0-.89-.33-.89h-1.78c-.46 0-.63.13-.84.72l-1.73 4.55h-2.74c-.38 0-.67-.08-.93 1.06-.08.55.05.76.55.76h2.41l-4.09 10.67a43.34 43.34 0 00-1.69 4.68c-.26 1.48.63 2.07 1.73 1.86 2.15-.38 5.23-2.62 8-6.12.76-1 .13-1.64-.64-.84a34.33 34.33 0 01-3.68 3.16c-1.1.72-1.65.21-1.27-.84l4.71-12.6h3.42c.76 0 1.14-.21 1.31-.76.29-.69.12-1.03-.63-1.03zm-63.6 11.9a40.24 40.24 0 01-3.8 3.33c-1.1.72-1.64.21-1.26-.84L128.17.97c.17-.42.08-1-.51-1a58.6 58.6 0 00-6 .68c-.34.08-.51.59-.13.71l2.28.85c.46.17.51.38.21 1.14l-8.84 22.97a43.34 43.34 0 00-1.69 4.68c-.25 1.48.63 2.07 1.73 1.86 2.28-.38 5.52-2.62 8.35-6.29.76-1.01.13-1.64-.63-.84zm43.39.08l2.49-5c1.35-2.74 1.61-4 1.61-4.93 0-1.81-.93-2.74-2.83-2.74-2.66 0-4.77 2.11-8 6.66-.89 1.22-1.48 2.15-2.66 3.67-.38.47-.67.42-.46-.13l1.64-4.09a17 17 0 001.35-4.47c0-1.09-.46-1.6-1.64-1.6-1.44 0-3.25.76-6.41 4.77-1.14 1.47 0 1.64.38 1.18.63-.64 2-2.07 2.91-2.87s1.72-.55 1.39.42a18.36 18.36 0 01-.8 2.24l-5 12.27c-.68 1.69 2.53 2.07 3.08.8 1.73-4 5.52-9 7.08-11.22 2.28-3.25 4.26-5.48 5.69-5.48.76 0 1.1.42 1.1 1.22a5.83 5.83 0 01-.59 2l-3.54 7.55c-1 2-1.94 4.13-2.11 4.68-.42 1.31.3 2 1.43 2 2 0 4.77-1.65 7.43-4.6.84-1 .21-1.64-.59-.93a29 29 0 01-3.12 2.41c-.92.59-1.56.12-1.26-.72.21-.6.97-2.16 1.43-3.09z"></path></svg></a></div><div class="Nav_rightContainer__CBCcP"><ul class="NavAccountLinks_root__8VKLM" data-event-element="account links"><li class="NavAccountLinks_navListItem__Lxooj"><a href="https://accounts.theatlantic.com/login/" class="NavAccountLinks_navLink__ctd7M NavAccountLinks_hideOnMobile__Eokx4">Sign In</a></li><li class="NavAccountLinks_navListItem__Lxooj"><a href="https://www.theatlantic.com/subscribe/navbar/" class="NavAccountLinks_subscribe__2DNuJ">Subscribe</a></li></ul></div></div></div></nav><div class="Nav_fixedPosPlaceholder__0nyHE"></div><div class="Nav_overlay__zlKnQ" data-testid="overlay"></div><div></div><main id="main-content" data-event-surface="article" data-flatplan-layout="feature" class=""><gpt-ad class="GptAd_root__pAvcS leaderboard-ad" format="leaderboard" sizes-at-0="" sizes-at-976="leaderboard"></gpt-ad><article class="ArticleLayout_article__RHFMN article-content-body"><header class="ArticleHero_root__3w7kV" data-event-module="hero"><div class=""><div class="ArticleLeadArt_root__nRSLU ArticleLeadArt_feature__DWkvD"><figure class="ArticleLeadFigure_root__Bj81R"><div class="ArticleLeadFigure_media__R1npW ArticleLeadFigure_featureBackground__TF2gc" data-flatplan-lead_figure_media="true"><picture><img alt="Cartoonish figures interact with the world through code." class="Image_root__XxsOp ArticleLeadArt_image__HZS4B ArticleLeadArt_featureMedia__8tbMf" sizes="(min-width: 1920px) 1920px, 100vw" srcSet="https://cdn.theatlantic.com/thumbor/6Ln6NcHA-BoP2VR_nwDteVywXn8=/108x230:1897x1236/640x360/media/img/2017/09/21/TheAtlantic_CodeFinal3/original.png 640w, https://cdn.theatlantic.com/thumbor/DhlrPoqTvIdglIRxFSSKNUHqg5E=/108x230:1897x1236/750x422/media/img/2017/09/21/TheAtlantic_CodeFinal3/original.png 750w, https://cdn.theatlantic.com/thumbor/5My8Q2BelrqNVX9AqSZlQrd14Cg=/108x230:1897x1236/850x478/media/img/2017/09/21/TheAtlantic_CodeFinal3/original.png 850w, https://cdn.theatlantic.com/thumbor/y82l57Br304M0irZ_SyHdfyQ9vE=/108x230:1897x1236/1536x864/media/img/2017/09/21/TheAtlantic_CodeFinal3/original.png 1536w" src="https://cdn.theatlantic.com/thumbor/iTzwN-qrMZdubIcExn-2pLs7t80=/108x230:1897x1236/1440x810/media/img/2017/09/21/TheAtlantic_CodeFinal3/original.png" id="article-lead-image" width="1440" height="810"/></picture></div><figcaption class="ArticleLeadFigure_caption__Byu7W ArticleLeadFigure_featureCaption__hxjjB" data-flatplan-lead_figure_caption="true">Lynn Scurfield</figcaption></figure></div><div class="ArticleHero_defaultArticleLockup__vb8lz"><div class="ArticleHero_rubric__e4rjD ArticleHero_featureRubric__uzMOp"><div class="ArticleRubric_root__HNhbf" id="rubric" data-flatplan-rubric="true"><a class="ArticleRubric_link__nl9hy" href="https://www.theatlantic.com/technology/" data-event-element="rubric">Technology</a></div></div><div class="ArticleHero_title__PQ4pC"><h1 class="ArticleTitle_root__VrZaG ArticleTitle_featureOrTwoCol__TRUC3" data-flatplan-title="true">The Coming Software Apocalypse</h1></div><div class="ArticleHero_dek__EqdkK" data-flatplan-description="true"><p class="ArticleDek_root__P3leE ArticleDek_feature__lHYTl">A small group of programmers wants to change how we code—before catastrophe strikes.</p></div><div class="ArticleHero_byline__iFT6A ArticleHero_featureByline__G7kFq"><div class="ArticleBylines_root__IBR5V"><address id="byline">By <a class="ArticleBylines_link__kNP4C" href="https://www.theatlantic.com/author/james-somers/" data-event-element="author" data-flatplan-author-link="true">James Somers</a></address></div></div></div></div><div class="ArticleHero_articleUtilityBar__JbQFj"><div class="ArticleHero_timestamp__bKhcB"><time class="ArticleTimestamp_root__b3bL6" dateTime="2017-09-26T15:10:42Z" data-flatplan-timestamp="true">September 26, 2017</time> </div><div class="ArticleHero_articleUtilityBarTools__ZHw8s"><div class="ArticleShare_root__Mq0RB" tabindex="-1"><button class="ArticleShare_shareButton__X0cIe" aria-haspopup="true" aria-controls=":Rp2pllhim:" aria-expanded="false" data-action="click share - expand" data-event-verb="shared" data-event-element="share dropdown"><span class="ArticleShare_text__oQKBy">Share</span><svg width="15" height="15" fill="none" xmlns="http://www.w3.org/2000/svg" class="ArticleShare_buttonIcon__B86vV"><path fill-rule="evenodd" clip-rule="evenodd" d="M7.335.272a.25.25 0 01.337 0l4.623 4.204a.25.25 0 01.017.353l-.336.37a.25.25 0 01-.353.016L8.004 1.926v7.9a.25.25 0 01-.25.25h-.5a.25.25 0 01-.25-.25V1.924l-3.62 3.291a.25.25 0 01-.353-.016l-.336-.37a.25.25 0 01.016-.353L7.335.272zM.5 7.545a.25.25 0 00-.25.25v6.75c0 .138.112.25.25.25h14a.25.25 0 00.25-.25v-6.75a.25.25 0 00-.25-.25H14a.25.25 0 00-.25.25v6H1.25v-6a.25.25 0 00-.25-.25H.5z" fill="currentColor"></path></svg></button></div><button class="SaveButton_saveButton__7LYFZ" aria-label="Save"><span class="SaveButton_text__fiZgx">Save<!-- --> </span><svg width="12" height="16" fill="none" xmlns="http://www.w3.org/2000/svg" class="SaveButton_icon__HFNiD SaveButton_unsaved__bP4MN"><path fill-rule="evenodd" clip-rule="evenodd" d="M6 10.828l5 3.31V1H1v13.139l5-3.31zM.776 15.486A.5.5 0 010 15.07V.5A.5.5 0 01.5 0h11a.5.5 0 01.5.5v14.57a.5.5 0 01-.776.416L6.138 12.12a.25.25 0 00-.276 0L.776 15.486z" fill="currentColor"></path><path fill-rule="evenodd" clip-rule="evenodd" d="M5.572 8.75c0 .138.111.25.25.25h.5a.25.25 0 00.25-.25V6.57H8.75A.25.25 0 009 6.32v-.5a.25.25 0 00-.25-.25H6.572V3.25a.25.25 0 00-.25-.25h-.5a.25.25 0 00-.25.25v2.32H3.25a.25.25 0 00-.25.25v.5c0 .138.112.25.25.25h2.322v2.18z" fill="currentColor"></path></svg></button></div></div><gpt-ad class="GptAd_root__pAvcS ArticleInjector_root__I7x9v s-native s-native--standard s-native--streamline article-injector-ad lead-article-ad ad-injector-article-start" format="injector" sizes-at-0="mobile-wide" targeting-pos="injector-article-start" sizes-at-976="desktop-wide"></gpt-ad></header><div><section class="ArticleBody_root__2gF81" data-event-module="article body" data-flatplan-body="true"><p class="ArticleParagraph_root__4mszW ArticleParagraph_dropcap__uIVzg" data-flatplan-paragraph="true" data-flatplan-dropcap="true">T<span class="smallcaps">here were</span> six hours during the night of April 10, 2014, when the entire population of Washington State had no 911 service. People who called for help got a busy signal. One Seattle woman dialed 911 at least 37 times while a stranger was trying to break into her house. When he finally crawled into her living room through a window, she picked up a kitchen knife. The man fled.</p><div class="ArticleLegacyHtml_root__WFd2I ArticleLegacyHtml_paragraph__cY6a3 ArticleLegacyHtml_standard__kC_zi" style="background-color:#333;color:#fff;padding:12px 24px"><iframe class="lazyload" data-src="https://w.soundcloud.com/player/?url=https%3A//api.soundcloud.com/tracks/346597527&amp;color=%23ff5500&amp;color=%23ff5500&amp;inverse=true&amp;auto_play=false&amp;show_user=true" frameborder="no" height="20" scrolling="no" style="background-color: #333" title="embedded interactive content" width="100%"></iframe><i class="audm--download-cta">To hear more feature stories, <a href="https://www.theatlantic.com/podcasts/audio-articles/?utm_source=audioarticleembed" style="color: #fff; text-decoration: underline;">see our full list</a> or <a href="https://goo.gl/ERK95W" style="color: #fff; text-decoration: underline;">get the Audm iPhone app.</a> </i></div><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">The 911 outage, at the time the largest ever reported, was traced to software running on a server in Englewood, Colorado. Operated by a systems provider named Intrado, the server kept a running counter of how many calls it had routed to 911 dispatchers around the country. Intrado programmers had set a threshold for how high the counter could go. They picked a number in the millions.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">Shortly before midnight on April 10, the counter exceeded that number, resulting in chaos. Because the counter was used to generate a unique identifier for each call, new calls were rejected. And because the programmers hadn’t anticipated the problem, they hadn’t created alarms to call attention to it. Nobody knew what was happening. Dispatch centers in Washington, California, Florida, the Carolinas, and Minnesota, serving 11 million Americans, struggled to make sense of reports that callers were getting busy signals. It took until morning to realize that Intrado’s software in Englewood was responsible, and that the fix was to change a single number.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">Not long ago, emergency calls were handled locally. Outages were small and easily diagnosed and fixed. The rise of cellphones and the promise of new capabilities—what if you could text 911? or send videos to the dispatcher?—drove the development of a more complex system that relied on the internet. For the first time, there could be such a thing as a national 911 outage. There have now been four in as many years.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">It’s been said that software is “eating the world.” More and more, critical systems that were once controlled mechanically, or by people, are coming to depend on code. This was perhaps never clearer than in the summer of 2015, when on a single day, United Airlines grounded its fleet because of a problem with its departure-management system; trading was suspended on the New York Stock Exchange after an upgrade; the front page of <em>The Wall Street Journal</em>’s website crashed; and Seattle’s 911 system went down again, this time because a different router failed. The simultaneous failure of so many software systems smelled at first of a coordinated cyberattack. Almost more frightening was the realization, late in the day, that it was just a coincidence.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">“When we had electromechanical systems, we used to be able to test them <em>exhaustively</em>,” says Nancy Leveson, a professor of aeronautics and astronautics at the Massachusetts Institute of Technology who has been studying software safety for 35 years. She became known for her report on the Therac-25, a radiation-therapy machine that killed six patients because of a software error. “We used to be able to think through all the things it could do, all the states it could get into.” The electromechanical interlockings that controlled train movements at railroad crossings, for instance, only had so many configurations; a few sheets of paper could describe the whole system, and you could run physical trains against each configuration to see how it would behave. Once you’d built and tested it, you knew exactly what you were dealing with.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">Software is different. Just by editing the text in a file somewhere, the same hunk of silicon can become an autopilot or an inventory-control system. This flexibility is software’s miracle, and its curse. Because it can be changed cheaply, software is constantly changed; and because it’s unmoored from anything physical—a program that is a thousand times more complex than another takes up the same actual space—it tends to grow without bound. “The problem,” Leveson wrote in a book, “is that we are attempting to build systems that are beyond our ability to intellectually manage.”</p><aside class="ArticlePullquote_root__z11cW" data-flatplan-pullquote="true">The software did exactly what it was told to do. The reason it failed is that it was told to do the wrong thing.</aside><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">Our standard framework for thinking about engineering failures—reflected, for instance, in regulations for medical devices—was developed shortly after World War II, before the advent of software, for electromechanical systems. The idea was that you make something reliable by making its parts reliable (say, you build your engine to withstand 40,000 takeoff-and-landing cycles) and by planning for the breakdown of those parts (you have two engines). But software doesn’t <em>break</em>. Intrado’s faulty threshold is not like the faulty rivet that leads to the crash of an airliner. The software did exactly what it was told to do. In fact it did it perfectly. The reason it failed is that it was told to do the wrong thing. Software failures are failures of understanding, and of imagination. Intrado actually had a backup router, which, had it been switched to automatically, would have restored 911 service almost immediately. But, as described in a report to the FCC, “the situation occurred at a point in the application logic that was not designed to perform any automated corrective actions.”</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">This is the trouble with making things out of code, as opposed to something physical. “The complexity,” as Leveson puts it, “is invisible to the eye.”</p><p class="ArticleParagraph_root__4mszW ArticleParagraph_dropcap__uIVzg" data-flatplan-paragraph="true" data-flatplan-dropcap="true">T<span class="smallcaps">he attempts now</span> underway to change how we make software all seem to start with the same premise: Code is too hard to think about. Before trying to understand the attempts themselves, then, it’s worth understanding why this might be: what it is about code that makes it so foreign to the mind, and so unlike anything that came before it.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">Technological progress used to change the way the world looked—you could watch the roads getting paved; you could see the skylines rise. Today you can hardly tell when something is remade, because so often it is remade by code. When you press your foot down on your car’s accelerator, for instance, you’re no longer controlling anything directly; there’s no mechanical link from the pedal to the throttle. Instead, you’re issuing a command to a piece of software that decides how much air to give the engine. The car is a computer you can sit inside of. The steering wheel and pedals might as well be keyboard keys.</p><div class="ArticleRelatedContentModule_root__nT4KN" data-flatplan-ignore="true"><div class="ArticleRelatedContentModule_notchedModule__ZRNgF"><section data-event-module="recirc" data-event-view="true" class="ArticleRelatedContentList_root__IjCAr"><h2 class="ArticleRelatedContentList_heading__EWCWq">Recommended Reading</h2><ul class="ArticleRelatedContentList_list__a_h1_"><li class="ArticleRelatedContentList_listItem__q_YvF"><div class="ArticleRelatedContentList_content__bmXvS" data-view-action="view link - recommended reading 1 - item 1" data-view-label="https://www.theatlantic.com/technology/archive/2017/09/you-are-already-living-inside-a-computer/539193/" data-event-position="1"><figure class="ArticleRelatedContentList_figure__7Oqmc"><a class="ArticleRelatedContentList_link__xwbss" href="https://www.theatlantic.com/technology/archive/2017/09/you-are-already-living-inside-a-computer/539193/" title="Read More: You Are Already Living Inside a Computer" data-event-element="image"><picture class="ArticleRelatedContentList_picture__SWkeN"><img alt="A person whose head has been replaced with a bulky desktop monitor" loading="lazy" class="Image_root__XxsOp Image_lazy__hYWHV ArticleRelatedContentList_image__jTtYO" srcSet="https://cdn.theatlantic.com/thumbor/BbAGugf5LKJ2oqsnwy7Crq5Rmnw=/333x0:1666x1333/80x80/media/img/mt/2017/09/ComputerLyfe/original.jpg, https://cdn.theatlantic.com/thumbor/UI-2ZFSAqm79pim79M1VojtIYCo=/333x0:1666x1333/160x160/media/img/mt/2017/09/ComputerLyfe/original.jpg 2x" src="https://cdn.theatlantic.com/thumbor/BbAGugf5LKJ2oqsnwy7Crq5Rmnw=/333x0:1666x1333/80x80/media/img/mt/2017/09/ComputerLyfe/original.jpg" width="80" height="80"/></picture></a></figure><div class="ArticleRelatedContentList_textWrapper__F_AL7"><h3 class="ArticleRelatedContentList_title__w7x7i"><a class="ArticleRelatedContentList_link__xwbss" href="https://www.theatlantic.com/technology/archive/2017/09/you-are-already-living-inside-a-computer/539193/" data-event-element="title">You Are Already Living Inside a Computer</a></h3><address class="ArticleRelatedContentList_byline__WPqCc"><a href="https://www.theatlantic.com/author/ian-bogost/" data-event-element="author"><span>Ian Bogost</span></a></address></div><div class="ArticleRelatedContentList_saveButtonWrapper__epZT3"><button class="SaveButton_saveButton__7LYFZ" aria-label="Save"><svg width="12" height="16" fill="none" xmlns="http://www.w3.org/2000/svg" class="SaveButton_icon__HFNiD SaveButton_unsaved__bP4MN"><path fill-rule="evenodd" clip-rule="evenodd" d="M6 10.828l5 3.31V1H1v13.139l5-3.31zM.776 15.486A.5.5 0 010 15.07V.5A.5.5 0 01.5 0h11a.5.5 0 01.5.5v14.57a.5.5 0 01-.776.416L6.138 12.12a.25.25 0 00-.276 0L.776 15.486z" fill="currentColor"></path><path fill-rule="evenodd" clip-rule="evenodd" d="M5.572 8.75c0 .138.111.25.25.25h.5a.25.25 0 00.25-.25V6.57H8.75A.25.25 0 009 6.32v-.5a.25.25 0 00-.25-.25H6.572V3.25a.25.25 0 00-.25-.25h-.5a.25.25 0 00-.25.25v2.32H3.25a.25.25 0 00-.25.25v.5c0 .138.112.25.25.25h2.322v2.18z" fill="currentColor"></path></svg></button></div></div></li><li class="ArticleRelatedContentList_listItem__q_YvF"><div class="ArticleRelatedContentList_content__bmXvS" data-view-action="view link - recommended reading 1 - item 2" data-view-label="https://www.theatlantic.com/technology/archive/2015/09/not-even-the-people-who-write-algorithms-really-know-how-they-work/406099/" data-event-position="2"><figure class="ArticleRelatedContentList_figure__7Oqmc"><a class="ArticleRelatedContentList_link__xwbss" href="https://www.theatlantic.com/technology/archive/2015/09/not-even-the-people-who-write-algorithms-really-know-how-they-work/406099/" title="Read More: Not Even the People Who Write Algorithms Really Know How They Work" data-event-element="image"><picture class="ArticleRelatedContentList_picture__SWkeN"><img alt="" loading="lazy" class="Image_root__XxsOp Image_lazy__hYWHV ArticleRelatedContentList_image__jTtYO" srcSet="https://cdn.theatlantic.com/thumbor/xX95QMYAVOjPIxXWbRKVxD1802M=/413x0:2418x2005/80x80/media/img/mt/2015/09/code/original.jpg, https://cdn.theatlantic.com/thumbor/TXxo92S1oBaImCawKRzCV6tvXCY=/413x0:2418x2005/160x160/media/img/mt/2015/09/code/original.jpg 2x" src="https://cdn.theatlantic.com/thumbor/xX95QMYAVOjPIxXWbRKVxD1802M=/413x0:2418x2005/80x80/media/img/mt/2015/09/code/original.jpg" width="80" height="80"/></picture></a></figure><div class="ArticleRelatedContentList_textWrapper__F_AL7"><h3 class="ArticleRelatedContentList_title__w7x7i"><a class="ArticleRelatedContentList_link__xwbss" href="https://www.theatlantic.com/technology/archive/2015/09/not-even-the-people-who-write-algorithms-really-know-how-they-work/406099/" data-event-element="title">Not Even the People Who Write Algorithms Really Know How They Work</a></h3><address class="ArticleRelatedContentList_byline__WPqCc"><a href="https://www.theatlantic.com/author/adrienne-lafrance/" data-event-element="author"><span>Adrienne LaFrance</span></a></address></div><div class="ArticleRelatedContentList_saveButtonWrapper__epZT3"><button class="SaveButton_saveButton__7LYFZ" aria-label="Save"><svg width="12" height="16" fill="none" xmlns="http://www.w3.org/2000/svg" class="SaveButton_icon__HFNiD SaveButton_unsaved__bP4MN"><path fill-rule="evenodd" clip-rule="evenodd" d="M6 10.828l5 3.31V1H1v13.139l5-3.31zM.776 15.486A.5.5 0 010 15.07V.5A.5.5 0 01.5 0h11a.5.5 0 01.5.5v14.57a.5.5 0 01-.776.416L6.138 12.12a.25.25 0 00-.276 0L.776 15.486z" fill="currentColor"></path><path fill-rule="evenodd" clip-rule="evenodd" d="M5.572 8.75c0 .138.111.25.25.25h.5a.25.25 0 00.25-.25V6.57H8.75A.25.25 0 009 6.32v-.5a.25.25 0 00-.25-.25H6.572V3.25a.25.25 0 00-.25-.25h-.5a.25.25 0 00-.25.25v2.32H3.25a.25.25 0 00-.25.25v.5c0 .138.112.25.25.25h2.322v2.18z" fill="currentColor"></path></svg></button></div></div></li><li class="ArticleRelatedContentList_listItem__q_YvF"><gpt-ad class="GptAd_root__pAvcS ad-native-article-related" lazy-load="2" format="native" sizes-at-0="native" targeting-pos="native-article-related" targeting-native="native"></gpt-ad><div class="ArticleRelatedContentList_content__bmXvS" data-view-action="view link - recommended reading 1 - item 3" data-view-label="https://www.theatlantic.com/magazine/archive/2021/01/james-suzman-work/617266/" data-event-position="3"><figure class="ArticleRelatedContentList_figure__7Oqmc"><a class="ArticleRelatedContentList_link__xwbss" href="https://www.theatlantic.com/magazine/archive/2021/01/james-suzman-work/617266/" title="Read More: How Civilization Broke Our Brains" data-event-element="image"><picture class="ArticleRelatedContentList_picture__SWkeN"><img alt="illustration of person in hammock with clouds shaped like inbox icons" loading="lazy" class="Image_root__XxsOp Image_lazy__hYWHV ArticleRelatedContentList_image__jTtYO" srcSet="https://cdn.theatlantic.com/thumbor/acUuBSvVHJDLr_yqMZUhZ4Q18Hw=/570x0:1695x1125/80x80/media/img/2020/12/CC_Thompson_Suzman/original.png, https://cdn.theatlantic.com/thumbor/G93oPVe8nQMWhPB_duXDpsAypNE=/570x0:1695x1125/160x160/media/img/2020/12/CC_Thompson_Suzman/original.png 2x" src="https://cdn.theatlantic.com/thumbor/acUuBSvVHJDLr_yqMZUhZ4Q18Hw=/570x0:1695x1125/80x80/media/img/2020/12/CC_Thompson_Suzman/original.png" width="80" height="80"/></picture></a></figure><div class="ArticleRelatedContentList_textWrapper__F_AL7"><h3 class="ArticleRelatedContentList_title__w7x7i"><a class="ArticleRelatedContentList_link__xwbss" href="https://www.theatlantic.com/magazine/archive/2021/01/james-suzman-work/617266/" data-event-element="title">How Civilization Broke Our Brains</a></h3><address class="ArticleRelatedContentList_byline__WPqCc"><a href="https://www.theatlantic.com/author/derek-thompson/" data-event-element="author"><span>Derek Thompson</span></a></address></div><div class="ArticleRelatedContentList_saveButtonWrapper__epZT3"><button class="SaveButton_saveButton__7LYFZ" aria-label="Save"><svg width="12" height="16" fill="none" xmlns="http://www.w3.org/2000/svg" class="SaveButton_icon__HFNiD SaveButton_unsaved__bP4MN"><path fill-rule="evenodd" clip-rule="evenodd" d="M6 10.828l5 3.31V1H1v13.139l5-3.31zM.776 15.486A.5.5 0 010 15.07V.5A.5.5 0 01.5 0h11a.5.5 0 01.5.5v14.57a.5.5 0 01-.776.416L6.138 12.12a.25.25 0 00-.276 0L.776 15.486z" fill="currentColor"></path><path fill-rule="evenodd" clip-rule="evenodd" d="M5.572 8.75c0 .138.111.25.25.25h.5a.25.25 0 00.25-.25V6.57H8.75A.25.25 0 009 6.32v-.5a.25.25 0 00-.25-.25H6.572V3.25a.25.25 0 00-.25-.25h-.5a.25.25 0 00-.25.25v2.32H3.25a.25.25 0 00-.25.25v.5c0 .138.112.25.25.25h2.322v2.18z" fill="currentColor"></path></svg></button></div></div></li></ul></section></div></div><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">Like everything else, the car has been computerized to enable new features. When a program is in charge of the throttle and brakes, it can slow you down when you’re too close to another car, or precisely control the fuel injection to help you save on gas. When it controls the steering, it can keep you in your lane as you start to drift, or guide you into a parking space. You couldn’t build these features without code. If you tried, a car might weigh 40,000 pounds, an immovable mass of clockwork.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">Software has enabled us to make the most intricate machines that have ever existed. And yet we have hardly noticed, because all of that complexity is packed into tiny silicon chips as millions and millions of lines of code. But just because we can’t see the complexity doesn’t mean that it has gone away.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">The programmer, the renowned Dutch computer scientist Edsger Dijkstra wrote in 1988, “has to be able to think in terms of conceptual hierarchies that are much deeper than a single mind ever needed to face before.” Dijkstra meant this as a warning. As programmers eagerly poured software into critical systems, they became, more and more, the linchpins of the built world—and Dijkstra thought they had perhaps overestimated themselves.</p><aside class="ArticlePullquote_root__z11cW" data-flatplan-pullquote="true">“Software engineers don’t understand the <em>problem</em> they’re trying to solve, and don’t care to.”</aside><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">What made programming so difficult was that it required you to think like a computer. The strangeness of it was in some sense more vivid in the early days of computing, when code took the form of literal ones and zeros. Anyone looking over a programmer’s shoulder as they pored over line after line like “100001010011” and “000010011110” would have seen just how alienated the programmer was from the actual problems they were trying to solve; it would have been impossible to tell whether they were trying to calculate artillery trajectories or simulate a game of tic-tac-toe. The introduction of programming languages like Fortran and C, which resemble English, and tools, known as “integrated development environments,” or IDEs, that help correct simple mistakes (like Microsoft Word’s grammar checker but for code), obscured, though did little to actually change, this basic alienation—the fact that the programmer didn’t work on a problem directly, but rather spent their days writing out instructions for a machine.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">“The problem is that software engineers don’t understand the <em>problem</em> they’re trying to solve, and don’t care to,” says Leveson, the MIT software-safety expert. The reason is that they’re too wrapped up in getting their code to work. “Software engineers like to provide all kinds of tools and stuff for coding errors,” she says, referring to IDEs. “The serious problems that have happened with software have to do with requirements, not coding errors.” When you’re writing code that controls a car’s throttle, for instance, what’s important is the rules about when and how and by how much to open it. But these systems have become so complicated that hardly anyone can keep them straight in their head. “There’s 100 million lines of code in cars now,” Leveson says. “You just cannot anticipate all these things.”</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">In September 2007, Jean Bookout was driving on the highway with her best friend in a Toyota Camry when the accelerator seemed to get stuck. When she took her foot off the pedal, the car didn’t slow down. She tried the brakes but they seemed to have lost their power. As she swerved toward an off-ramp going 50 miles per hour, she pulled the emergency brake. The car left a skid mark 150 feet long before running into an embankment by the side of the road. The passenger was killed. Bookout woke up in a hospital a month later.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">The incident was one of many in a nearly decade-long investigation into claims of so-called unintended acceleration in Toyota cars. Toyota blamed the incidents on poorly designed floor mats, “sticky” pedals, and driver error, but outsiders suspected that faulty software might be responsible. The National Highway Traffic Safety Administration enlisted software experts from NASA to perform an intensive review of Toyota’s code. After nearly 10 months, the NASA team hadn’t found evidence that software was the cause—but said they couldn’t prove it wasn’t.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">It was during litigation of the Bookout accident that someone finally found a convincing connection. Michael Barr, an expert witness for the plaintiff, had a team of software experts spend 18 months with the Toyota code, picking up where NASA left off. Barr described what they found as “spaghetti code,” programmer lingo for software that has become a tangled mess. Code turns to spaghetti when it accretes over many years, with feature after feature piling on top of, and being woven around, what’s already there; eventually the code becomes impossible to follow, let alone to test exhaustively for flaws.</p><aside class="ArticlePullquote_root__z11cW" data-flatplan-pullquote="true">“If the software malfunctions and the same program that crashed is supposed to save the day, it can’t.”</aside><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true"><a data-event-element="inline link" id="Key Tasks" name="Key%20Tasks"></a>Using the same model as the Camry involved in the accident, Barr’s team demonstrated that there were more than 10 million ways for key tasks on the onboard computer to fail, potentially leading to unintended acceleration.<a data-event-element="inline link" href="#Correction">*</a> They showed that as little as a single bit flip—a one in the computer’s memory becoming a zero or vice versa—could make a car run out of control. The fail-safe code that Toyota had put in place wasn’t enough to stop it. “You have software watching the software,” Barr testified. “If the software malfunctions and the same program or same app that is crashed is supposed to save the day, it can’t save the day because it is not working.”</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">Barr’s testimony made the case for the plaintiff, resulting in $3 million in damages for Bookout and her friend’s family. According to <em>The New York Times</em>, it was the first of many similar cases against Toyota to bring to trial problems with the electronic throttle-control system, and the first time Toyota was found responsible by a jury for an accident involving unintended acceleration. The parties decided to settle the case before punitive damages could be awarded. In all, Toyota recalled more than 9 million cars, and paid nearly $3 billion in settlements and fines related to unintended acceleration.</p><p class="ArticleParagraph_root__4mszW ArticleParagraph_dropcap__uIVzg" data-flatplan-paragraph="true" data-flatplan-dropcap="true">T<span class="smallcaps">here will be</span> more bad days for software. It's important that we get better at making it, because if we don't, and as software becomes more sophisticated and connected—as it takes control of more critical functions—those days could get worse.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">The problem is that programmers are having a hard time keeping up with their own creations. Since the 1980s, the way programmers work and the tools they use have changed remarkably little. There is a small but growing chorus that worries the status quo is unsustainable. “Even very good programmers are struggling to make sense of the systems that they are working with,” says Chris Granger, a software developer who worked as a lead at Microsoft on Visual Studio, an IDE that costs $1,199 a year and is used by nearly a third of all professional programmers. He told me that while he was at Microsoft, he arranged an end-to-end study of Visual Studio, the only one that had ever been done. For a month and a half, he watched behind a one-way mirror as people wrote code. “How do they use tools? How do they think?” he said. “How do they <em>sit </em>at the computer, do they touch the mouse, do they not touch the mouse? All these things that we have dogma around that we haven’t actually tested empirically.”</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">The findings surprised him. “Visual Studio is one of the single largest pieces of software in the world,” he said. “It’s over 55 million lines of code. And one of the things that I found out in this study is more than 98 percent of it is completely irrelevant. All this work had been put into this thing, but it missed the fundamental problems that people faced. And the biggest one that I took away from it was that basically <em>people are playing computer inside their head</em>.” Programmers were like chess players trying to play with a blindfold on—so much of their mental energy is spent just trying to picture where the pieces are that there’s hardly any left over to think about the game itself.</p><aside class="ArticlePullquote_root__z11cW" data-flatplan-pullquote="true">Computers had doubled in power every 18 months for the last 40 years. Why hadn’t programming changed?</aside><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">John Resig had been noticing the same thing among his students. Resig is a celebrated programmer of JavaScript—software he wrote powers over half of all websites—and a tech lead at the online-education site Khan Academy. In early 2012, he had been struggling with the site’s computer-science curriculum. Why was it so hard to learn to program? The essential problem seemed to be that code was so abstract. Writing software was not like making a bridge out of popsicle sticks, where you could see the sticks and touch the glue. To “make” a program, you typed words. When you wanted to change the behavior of the program, be it a game, or a website, or a simulation of physics, what you actually changed was text. So the students who did well—in fact the only ones who survived at all—were those who could step through that text one instruction at a time in their head, thinking the way a computer would, trying to keep track of every intermediate calculation. Resig, like Granger, started to wonder if it had to be that way. Computers had doubled in power every 18 months for the last 40 years. Why hadn’t programming changed?</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">The fact that the two of them were thinking about the same problem in the same terms, at the same time, was not a coincidence. They had both just seen the same remarkable talk, given to a group of software-engineering students in a Montreal hotel by a computer researcher named Bret Victor. The talk, which went viral when it was posted online in February 2012, seemed to be making two bold claims. The first was that the way we make software is fundamentally broken. The second was that Victor knew how to fix it.</p><p class="ArticleParagraph_root__4mszW ArticleParagraph_dropcap__uIVzg" data-flatplan-paragraph="true" data-flatplan-dropcap="true">B<span class="smallcaps">ret Victor does</span> not like to write code. “It sounds weird,” he says. “When I want to make a thing, especially when I want to create something in software, there’s this initial layer of disgust that I have to push through, where I’m not manipulating the thing that I want to make, I’m writing a bunch of text into a text editor.”</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">“There’s a pretty strong conviction that that’s the wrong way of doing things.”</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">Victor has the mien of David Foster Wallace, with a lightning intelligence that lingers beneath a patina of aw-shucks shyness. He is 40 years old, with traces of gray and a thin, undeliberate beard. His voice is gentle, mournful almost, but he wants to share what’s in his head, and when he gets on a roll he’ll seem to skip syllables, as though outrunning his own vocal machinery.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">Though he runs a lab that studies the future of computing, he seems less interested in technology per se than in the minds of the people who use it. Like any good toolmaker, he has a way of looking at the world that is equal parts technical and humane. He graduated top of his class at the California Institute of Technology for electrical engineering, and then went on, after grad school at the University of California, Berkeley, to work at a company that develops music synthesizers. It was a problem perfectly matched to his dual personality: He could spend as much time thinking about the way a performer makes music with a keyboard—the way it becomes an extension of their hands—as he could thinking about the mathematics of digital signal processing.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">By the time he gave the talk that made his name, the one that Resig and Granger saw in early 2012, Victor had finally landed upon the principle that seemed to thread through all of his work. (He actually called the talk “Inventing on Principle.”) The principle was this: “Creators need an immediate connection to what they’re creating.” The problem with programming was that it violated the principle. That’s why software systems were so hard to think about, and so rife with bugs: The programmer, staring at a page of text, was abstracted from whatever it was they were actually making.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">“Our current conception of what a computer program is,” he said, is “derived straight from Fortran and ALGOL in the late ’50s. Those languages were designed for punch cards.” That code now takes the form of letters on a screen in a language like C or Java (derivatives of Fortran and ALGOL), instead of a stack of cards with holes in it, doesn’t make it any less dead, any less indirect.</p><aside class="ArticlePullquote_root__z11cW" data-flatplan-pullquote="true">To Victor, the idea that people were trying to understand cancer by staring at a text editor was appalling.</aside><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">There is an analogy to word processing. It used to be that all you could see in a program for writing documents was the text itself, and to change the layout or font or margins, you had to write special “control codes,” or commands that would tell the computer that, for instance, “this part of the text should be in italics.” The trouble was that you couldn’t see the effect of those codes until you printed the document. It was hard to predict what you were going to get. You had to imagine how the codes were going to be interpreted by the computer—that is, you had to play computer in your head.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">Then WYSIWYG (pronounced “wizzywig”) came along. It stood for “What You See Is What You Get.” When you marked a passage as being in italics, the letters tilted right there on the screen. If you wanted to change the margin, you could drag a ruler at the top of the screen—and <em>see</em> the effect of that change. The document thereby came to feel like something real, something you could poke and prod at. Just by looking you could tell if you’d done something wrong. Control of a sophisticated system—the document’s layout and formatting engine—was made accessible to anyone who could click around on a page.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">Victor’s point was that programming itself should be like that. For him, the idea that people were doing important work, like designing adaptive cruise-control systems or trying to understand cancer, by staring at a text editor, was appalling. And it was the proper job of programmers to ensure that someday they wouldn’t have to.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">There was precedent enough to suggest that this wasn’t a crazy idea. Photoshop, for instance, puts powerful image-processing algorithms in the hands of people who might not even know what an algorithm is. It’s a complicated piece of software, but complicated in the way a good synth is complicated, with knobs and buttons and sliders that the user learns to play like an instrument. Squarespace, a company that is perhaps best known for advertising aggressively on podcasts, makes a tool that lets users build websites by pointing and clicking, instead of by writing code in HTML and CSS. It is powerful enough to do work that once would have been done by a professional web designer.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">But those were just a handful of examples. The overwhelming reality was that when someone wanted to do something interesting with a computer, they had to write code. Victor, who is something of an idealist, saw this not so much as an opportunity but as a moral failing of programmers at large. His talk was a call to arms.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">At the heart of it was a series of demos that tried to show just how primitive the available tools were for various problems—circuit design, computer animation, debugging algorithms—and what better ones might look like. His demos were virtuosic. The one that captured everyone’s imagination was, ironically enough, the one that on its face was the most trivial. It showed a split screen with a game that looked like <em>Mario</em> on one side and the code that controlled it on the other. As Victor changed the code, things in the game world changed: He decreased one number, the strength of gravity, and the Mario character floated; he increased another, the player’s speed, and Mario raced across the screen.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">Suppose you wanted to design a level where Mario, jumping and bouncing off of a turtle, would <em>just</em> make it into a small passageway. Game programmers were used to solving this kind of problem in two stages: First, you stared at your code—the code controlling how high Mario jumped, how fast he ran, how bouncy the turtle’s back was—and made some changes to it in your text editor, using your imagination to predict what effect they’d have. Then, you’d replay the game to see what actually happened.</p><figure class="ArticleLegacyHtml_root__WFd2I ArticleLegacyHtml_standard__kC_zi"><video autoplay="autoplay" loop="loop" muted="muted" playsinline="playsinline" poster="https://cdn.theatlantic.com/assets/media/files/videos/screen_shot_2017-09-20_at_10.09.49_am.jpg" webkit-playsinline="webkit-playsinline" width="100%"><source src="https://cdn.theatlantic.com/assets/media/files/videos/bret-victor-inventing-on-principle.mp4"/> Shadow Marios move on the left half of a screen as a mouse drags sliders on the right half.</video> <figcaption class="credit"><a href="https://vimeo.com/36579366">CUSEC / Vimeo</a></figcaption></figure><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">Victor wanted something more immediate. “If you have a process in time,” he said, referring to Mario’s path through the level, “and you want to see changes immediately, you have to map time to space.” He hit a button that showed not just where Mario was right now, but where he would be at every moment in the future: a curve of shadow Marios stretching off into the far distance. What’s more, this projected path was reactive: When Victor changed the game’s parameters, now controlled by a quick drag of the mouse, the path’s shape changed. It was like having a god’s-eye view of the game. The whole problem had been reduced to playing with different parameters, as if adjusting levels on a stereo receiver, until you got Mario to thread the needle. With the right interface, it was almost as if you weren’t working with code at all; you were manipulating the game’s behavior directly.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">When the audience first saw this in action, they literally gasped. They knew they weren’t looking at a kid’s game, but rather the future of their industry. <em>Most</em> software involved behavior that unfolded, in complex ways, over time, and Victor had shown that if you were imaginative enough, you could develop ways to see that behavior and change it, as if playing with it in your hands. One programmer who saw the talk wrote later: “Suddenly all of my tools feel obsolete.”</p><p class="ArticleParagraph_root__4mszW ArticleParagraph_dropcap__uIVzg" data-flatplan-paragraph="true" data-flatplan-dropcap="true">W<span class="smallcaps">hen John Resig</span> saw the “Inventing on Principle” talk, he scrapped his plans for the Khan Academy programming curriculum. He wanted the site’s programming exercises to work just like Victor’s demos. On the left-hand side you’d have the code, and on the right, the running program: a picture or game or simulation. If you changed the code, it’d instantly change the picture. “In an environment that is truly responsive,” Resig wrote about the approach, “you can completely change the model of how a student learns ... [They] can now immediately see the result and intuit how underlying systems inherently work without ever following an explicit explanation.” Khan Academy has become perhaps the largest computer-programming class in the world, with a million students, on average, actively using the program each month.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">Chris Granger, who had worked at Microsoft on Visual Studio, was likewise inspired. Within days of seeing a video of Victor’s talk, in January of 2012, he built a prototype of a new programming environment. Its key capability was that it would give you instant feedback on your program’s behavior. You’d see what your system was doing right next to the code that controlled it. It was like taking off a blindfold. Granger called the project “Light Table.”</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">In April of 2012, he sought funding for Light Table on Kickstarter. In programming circles, it was a sensation. Within a month, the project raised more than $200,000. The ideas spread. The notion of <em>liveness</em>, of being able to see data flowing through your program instantly, made its way into flagship programming tools offered by Google and Apple. The default language for making new iPhone and Mac apps, called Swift, was developed by Apple from the ground up to support an environment, called Playgrounds, that was directly inspired by Light Table.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">But seeing the impact that his talk ended up having, Bret Victor was disillusioned. “A lot of those things seemed like misinterpretations of what I was saying,” he said later. He knew something was wrong when people began to invite him to conferences to talk about programming tools. “Everyone thought I was interested in programming environments,” he said. Really he was interested in how people see and understand systems—as he puts it, in the “visual representation of dynamic behavior.” Although code had increasingly become the tool of choice for <em>creating </em>dynamic behavior, it remained one of the worst tools for understanding it. The point of “Inventing on Principle” was to show that you could mitigate that problem by making the connection between a system’s behavior and its code immediate.</p><aside class="ArticlePullquote_root__z11cW" data-flatplan-pullquote="true">“I’m not sure that programming has to exist at all.”</aside><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">In a pair of later talks, “Stop Drawing Dead Fish” and “Drawing Dynamic Visualizations,” Victor went one further. He demoed two programs he’d built—the first for animators, the second for scientists trying to visualize their data—each of which took a process that used to involve writing lots of custom code and reduced it to playing around in a WYSIWYG interface. Victor suggested that the same trick could be pulled for nearly every problem where code was being written today. “I’m not sure that programming has to exist at all,” he told me. “Or at least software developers.” In his mind, a software developer’s proper role was to create tools that removed the need for software developers. Only then would people with the most urgent computational problems be able to grasp those problems directly, without the intermediate muck of code.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">Of course, to do that, you’d have to get programmers themselves on board. In a recent essay, Victor implored professional software developers to stop pouring their talent into tools for building apps like Snapchat and Uber. “The inconveniences of daily life are not the significant problems,” he wrote. Instead, they should focus on scientists and engineers—as he put it to me, “these people that are doing work that actually matters, and critically matters, and using really, really bad tools.” Exciting work of this sort, in particular a class of tools for “model-based design,” was already underway, he wrote, and had been for years, but most programmers knew nothing about it.</p><p class="ArticleParagraph_root__4mszW ArticleParagraph_dropcap__uIVzg" data-flatplan-paragraph="true" data-flatplan-dropcap="true">“I<span class="smallcaps">f you really</span> look hard at all the industrial goods that you’ve got out there, that you’re using, that companies are using, the only non-industrial stuff that you have inside this is the code.” Eric Bantégnie is the founder of Esterel Technologies (now owned by ANSYS), a French company that makes tools for building safety-critical software. Like Victor, Bantégnie doesn’t think engineers should develop large systems by typing millions of lines of code into an IDE. “Nobody would build a car by hand,” he says. “Code is still, in many places, handicraft. When you’re crafting manually 10,000 lines of code, that’s okay. But you have systems that have 30 million lines of code, like an Airbus, or 100 million lines of code, like your Tesla or high-end cars—that’s becoming very, very complicated.”</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">Bantégnie’s company is one of the pioneers in the industrial use of model-based design, in which you no longer write code directly. Instead, you create a kind of flowchart that describes the rules your program should follow (the “model”), and the computer generates code for you based on those rules. If you were making the control system for an elevator, for instance, one rule might be that when the door is open, and someone presses the button for the lobby, you should close the door and start moving the car. In a model-based design tool, you’d represent this rule with a small diagram, as though drawing the logic out on a whiteboard, made of boxes that represent different states—like “door open,” “moving,” and “door closed”—and lines that define how you can get from one state to the other. The diagrams make the system’s rules obvious: Just by looking, you can see that the only way to get the elevator moving is to close the door, or that the only way to get the door open is to stop.</p><aside class="ArticlePullquote_root__z11cW" data-flatplan-pullquote="true">“The people know how to code. The problem is <em>what</em> to code.”</aside><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">It’s not quite Photoshop. The beauty of Photoshop, of course, is that the picture you’re manipulating on the screen <em>is</em> the final product. In model-based design, by contrast, the picture on your screen is more like a blueprint. Still, making software this way is qualitatively different than traditional programming. In traditional programming, your task is to take complex rules and translate them into code; most of your energy is spent doing the translating, rather than thinking about the rules themselves. In the model-based approach, all you <em>have</em> is the rules. So that’s what you spend your time thinking about. It’s a way of focusing less on the machine and more on the problem you’re trying to get it to solve.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">“Typically the main problem with software coding—and I’m a coder myself,” Bantégnie says, “is not the skills of the coders. The people know how to code. The problem is <em>what</em> to code. Because most of the requirements are kind of natural language, ambiguous, and a requirement is never extremely precise, it’s often understood differently by the guy who’s supposed to code.”</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">On this view, software becomes unruly because the media for describing what software <em>should</em> do—conversations, prose descriptions, drawings on a sheet of paper—are too different from the media describing what software <em>does</em> do, namely, code itself. Too much is lost going from one to the other. The idea behind model-based design is to close the gap. The very same model is used both by system designers to express what they want and by the computer to automatically generate code.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">Of course, for this approach to succeed, much of the work has to be done well before the project even begins. Someone first has to build a tool for developing models that are natural for people—that feel just like the notes and drawings they’d make on their own—while still being unambiguous enough for a computer to understand. They have to make a program that turns these models into real code. And finally they have to prove that the generated code will always do what it’s supposed to. “We have benefited from fortunately 20 years of initial background work,” Bantégnie says.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">Esterel Technologies, which was acquired by ANSYS in 2012, grew out of research begun in the 1980s by the French nuclear and aerospace industries, who worried that as safety-critical code ballooned in complexity, it was getting harder and harder to keep it free of bugs. “I started in 1988,” says Emmanuel Ledinot, the Head of Scientific Studies for Dassault Aviation, a French manufacturer of fighter jets and business aircraft. “At the time, I was working on military avionics systems. And the people in charge of integrating the systems, and debugging them, had noticed that the number of bugs was increasing.” The 80s had seen a surge in the number of onboard computers on planes. Instead of a single flight computer, there were now dozens, each responsible for highly specialized tasks related to control, navigation, and communications. Coordinating these systems to fly the plane as data poured in from sensors and as pilots entered commands required a symphony of perfectly timed reactions. “The handling of these hundreds of and even thousands of possible events in the right order, at the right time,” Ledinot says, “was diagnosed as the main cause of the bug inflation.”</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">Ledinot decided that writing such convoluted code by hand was no longer sustainable. It was too hard to understand what it was doing, and almost impossible to verify that it would work correctly. He went looking for something new. “You must understand that to change tools is extremely expensive in a process like this,” he said in a talk. “You don’t take this type of decision unless your back is against the wall.”</p><aside class="ArticlePullquote_root__z11cW" data-flatplan-pullquote="true">Most programmers <em>like</em> code. At least they understand it.</aside><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">He began collaborating with Gerard Berry, a computer scientist at INRIA, the French computing-research center, on a tool called Esterel—a portmanteau of the French for “real-time.” The idea behind Esterel was that while traditional programming languages might be good for describing simple procedures that happened in a predetermined order—like a recipe—if you tried to use them in systems where lots of events could happen at nearly any time, in nearly any order—like in the cockpit of a plane—you inevitably got a mess. And a mess in control software was dangerous. In a paper, Berry went as far as to predict that “low-level programming techniques will not remain acceptable for large safety-critical programs, since they make behavior understanding and analysis almost impracticable.”</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">Esterel was designed to make the computer handle this complexity for you. That was the promise of the model-based approach: Instead of writing normal programming code, you created a model of the system’s behavior—in this case, a model focused on how individual events should be handled, how to prioritize events, which events depended on which others, and so on. The model becomes the detailed blueprint that the computer would use to do the actual programming.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">Ledinot and Berry worked for nearly 10 years to get Esterel to the point where it could be used in production. “It was in 2002 that we had the first operational software-modeling environment with automatic code generation,” Ledinot told me, “and the first embedded module in Rafale, the combat aircraft.” Today, the ANSYS SCADE product family (for “safety-critical application development environment”) is used to generate code by companies in the aerospace and defense industries, in nuclear power plants, transit systems, heavy industry, and medical devices. “My initial dream was to have SCADE-generated code in every plane in the world,” Bantégnie, the founder of Esterel Technologies, says, “and we’re not very far off from that objective.” Nearly all safety-critical code on the Airbus A380, including the system controlling the plane’s flight surfaces, was generated with ANSYS SCADE products.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">Part of the draw for customers, especially in aviation, is that while it is possible to build highly reliable software by hand, it can be a Herculean effort. Ravi Shivappa, the VP of group software engineering at Meggitt PLC, an ANSYS customer which builds components for airplanes, like pneumatic fire detectors for engines, explains that traditional projects begin with a massive requirements document in English, which specifies everything the software should do. (A requirement might be something like, “When the pressure in this section rises above a threshold, open the safety valve, unless the manual-override switch is turned on.”) The problem with describing the requirements this way is that when you implement them in code, you have to painstakingly check that each one is satisfied. And when the customer changes the requirements, the code has to be changed, too, and tested extensively to make sure that nothing else was broken in the process.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">The cost is compounded by exacting regulatory standards. The FAA is fanatical about software safety. The agency mandates that every requirement for a piece of safety-critical software be traceable to the lines of code that implement it, and vice versa. So every time a line of code changes, it must be retraced to the corresponding requirement in the design document, and you must be able to demonstrate that the code actually satisfies the requirement. The idea is that if something goes wrong, you’re able to figure out why; the practice brings order and accountability to large codebases. But, Shivappa says, “it’s a very labor-intensive process.” He estimates that before they used model-based design, on a two-year-long project only two to three months was spent writing code—the rest was spent working on the documentation.</p><aside class="ArticlePullquote_root__z11cW" data-flatplan-pullquote="true">We already know how to make complex software reliable, but in so many places, we’re choosing not to.</aside><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">As Bantégnie explains, the beauty of having a computer turn your requirements into code, rather than a human, is that you can be sure—in fact you can mathematically prove—that the generated code actually satisfies those requirements. Much of the benefit of the model-based approach comes from being able to add requirements on the fly while still ensuring that existing ones are met; with every change, the computer can verify that your program still works. You’re free to tweak your blueprint without fear of introducing new bugs. Your code is, in FAA parlance, “correct by construction.”</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">Still, most software, even in the safety-obsessed world of aviation, is made the old-fashioned way, with engineers writing their requirements in prose and programmers coding them up in a programming language like C. As Bret Victor made clear in his essay, model-based design is relatively unusual. “A lot of people in the FAA think code generation is magic, and hence call for greater scrutiny,” Shivappa told me.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">Most programmers feel the same way. They <em>like</em> code. At least they understand it. Tools that write your code for you and verify its correctness using the mathematics of “finite-state machines” and “recurrent systems” sound esoteric and hard to use, if not just too good to be true.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">It is a pattern that has played itself out before. Whenever programming has taken a step away from the writing of literal ones and zeros, the loudest objections have come from programmers. Margaret Hamilton, a celebrated software engineer on the Apollo missions—in fact the coiner of the phrase “software engineering”—told me that during her first year at the Draper lab at MIT, in 1964, she remembers a meeting where one faction was fighting the other about transitioning away from “some very low machine language,” as close to ones and zeros as you could get, to “assembly language.” “The people at the lowest level were fighting to keep it. And the arguments were so similar: ‘Well how do we know assembly language is going to do it right?’”</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">“Guys on one side, their faces got red, and they started screaming,” she said. She said she was “amazed how emotional they got.”</p><aside class="ArticlePullquote_root__z11cW" data-flatplan-pullquote="true">You could do all the testing you wanted and you’d never find all the bugs.</aside><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">Emmanuel Ledinot, of Dassault Aviation, pointed out that when assembly language was itself phased out in favor of the programming languages still popular today, like C, it was the assembly programmers who were skeptical this time. No wonder, he said, that “people are not so easily transitioning to model-based software development: They perceive it as another opportunity to lose control, even more than they have already.”</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">The bias against model-based design, sometimes known as model-driven engineering, or MDE, is in fact so ingrained that according to a recent paper, “Some even argue that there is a stronger need to investigate people’s perception of MDE than to research new MDE technologies.”</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">Which sounds almost like a joke, but for proponents of the model-based approach, it’s an important point: We already know how to make complex software reliable, but in so many places, we’re choosing not to. Why?</p><p class="ArticleParagraph_root__4mszW ArticleParagraph_dropcap__uIVzg" data-flatplan-paragraph="true" data-flatplan-dropcap="true">I<span class="smallcaps">n 2011, Chris</span> Newcombe had been working at Amazon for almost seven years, and had risen to be a principal engineer. He had worked on some of the company’s most critical systems, including the retail-product catalog and the infrastructure that managed every Kindle device in the world. He was a leader on the highly prized Amazon Web Services team, which maintains cloud servers for some of the web’s biggest properties, like Netflix, Pinterest, and Reddit. Before Amazon, he’d helped build the backbone of Steam, the world’s largest online-gaming service. He is one of those engineers whose work quietly keeps the internet running. The products he’d worked on were considered massive successes. But all he could think about was that buried deep in the designs of those systems were disasters waiting to happen.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">“Human intuition is poor at estimating the true probability of supposedly ‘extremely rare’ combinations of events in systems operating at a scale of millions of requests per second,” he wrote in a paper. “That human fallibility means that some of the more subtle, dangerous bugs turn out to be errors in design; the code faithfully implements the intended design, but the design fails to correctly handle a particular ‘rare’ scenario.”</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">Newcombe was convinced that the algorithms behind truly critical systems—systems storing a significant portion of the web’s data, for instance—ought to be not just good, but perfect. A single subtle bug could be catastrophic. But he knew how hard bugs were to find, especially as an algorithm grew more complex. You could do all the testing you wanted and you’d never find them all.</p><aside class="ArticlePullquote_root__z11cW" data-flatplan-pullquote="true">“Few programmers write even a rough sketch of what their programs will do before they start coding.”</aside><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">This is why he was so intrigued when, in the appendix of a paper he’d been reading, he came across a strange mixture of math and code—or what looked like code—that described an algorithm in something called “TLA+.” The surprising part was that this description was said to be mathematically precise: An algorithm written in TLA+ could in principle be <em>proven</em> correct. In practice, it allowed you to create a realistic model of your problem and test it not just thoroughly, but <em>exhaustively</em>. This was exactly what he’d been looking for: a language for writing perfect algorithms.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">TLA+, which stands for “Temporal Logic of Actions,” is similar in spirit to model-based design: It’s a language for writing down the requirements—TLA+ calls them “specifications”—of computer programs. These specifications can then be completely verified by a computer. That is, before you write any code, you write a concise outline of your program’s logic, along with the constraints you need it to satisfy (say, if you were programming an ATM, a constraint might be that you can never withdraw the same money twice from your checking account). TLA+ then exhaustively checks that your logic does, in fact, satisfy those constraints. If not, it will show you exactly how they could be violated.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">The language was invented by Leslie Lamport, a Turing Award–winning computer scientist. With a big white beard and scruffy white hair, and kind eyes behind large glasses, Lamport looks like he might be one of the friendlier professors at the American Hogwarts. Now at Microsoft Research, he is known as one of the pioneers of the theory of “distributed systems,” which describes any computer system made of multiple parts that communicate with each other. Lamport’s work laid the foundation for many of the systems that power the modern web.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">For Lamport, a major reason today’s software is so full of bugs is that programmers jump straight into writing code. “Architects draw detailed plans before a brick is laid or a nail is hammered,” he wrote in an article. “But few programmers write even a rough sketch of what their programs will do before they start coding.” Programmers are drawn to the nitty-gritty of coding because code is what makes programs go; spending time on anything else can seem like a distraction. And there is a patient joy, a meditative kind of satisfaction, to be had from puzzling out the micro-mechanics of code. But code, Lamport argues, was never meant to be a medium for thought. “It really does constrain your ability to think when you’re thinking in terms of a programming language,” he says. Code makes you miss the forest for the trees: It draws your attention to the working of individual pieces, rather than to the bigger picture of how your program fits together, or what it’s supposed to do—and whether it actually does what you think. This is why Lamport created TLA+. As with model-based design, TLA+ draws your focus to the high-level structure of a system, its essential logic, rather than to the code that implements it.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">Newcombe and his colleagues at Amazon would go on to use TLA+ to find subtle, critical bugs in major systems, including bugs in the core algorithms behind S3, regarded as perhaps the most reliable storage engine in the world. It is now used widely at the company. In the tiny universe of people who had ever used TLA+, their success was not so unusual. An intern at Microsoft used TLA+ to catch a bug that could have caused every Xbox in the world to crash after four hours of use. Engineers at the European Space Agency used it to rewrite, with 10 times less code, the operating system of a probe that was the first to ever land softly on a comet. Intel uses it regularly to verify its chips.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">But TLA+ occupies just a small, far corner of the mainstream, if it can be said to take up any space there at all. Even to a seasoned engineer like Newcombe, the language read at first as bizarre and esoteric—a zoo of symbols. For Lamport, this is a failure of education. Though programming was born in mathematics, it has since largely been divorced from it. Most programmers aren’t very fluent in the kind of math—logic and set theory, mostly—that you need to work with TLA+. “Very few programmers—and including very few teachers of programming—understand the very basic concepts and how they’re applied in practice. And they seem to think that all they need is code,” Lamport says. “The idea that there’s some higher level than the code in which you need to be able to think precisely, and that mathematics actually allows you to think precisely about it, is just completely foreign. Because they never learned it.”</p><aside class="ArticlePullquote_root__z11cW" data-flatplan-pullquote="true">“I hope people won’t be allowed to write programs if they don’t understand these simple things.”</aside><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">Lamport sees this failure to think mathematically about what they’re doing as the problem of modern software development in a nutshell: The stakes keep rising, but programmers aren’t stepping up—they haven’t developed the chops required to handle increasingly complex problems. “In the 15th century,” he said, “people used to build cathedrals without knowing calculus, and nowadays I don’t think you’d <em>allow</em> anyone to build a cathedral without knowing calculus. And I would hope that after some suitably long period of time, people won’t be allowed to write programs if they don’t understand these simple things.”</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">Newcombe isn’t so sure that it’s the programmer who is to blame. “I’ve heard from Leslie that he thinks programmers are afraid of math. I’ve found that programmers aren’t aware—or don’t believe—that math can help them handle complexity. Complexity is the biggest challenge for programmers.” The real problem in getting people to use TLA+, he said, was convincing them it wouldn’t be a waste of their time. Programmers, as a species, are relentlessly pragmatic. Tools like TLA+ reek of the ivory tower. When programmers encounter “formal methods” (so called because they involve mathematical, “formally” precise descriptions of programs), their deep-seated instinct is to recoil.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">Most programmers who took computer science in college have briefly encountered formal methods. Usually they’re demonstrated on something trivial, like a program that counts up from zero; the student’s job is to mathematically prove that the program does, in fact, count up from zero.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">“I needed to change people’s perceptions on what formal methods were,” Newcombe told me. Even Lamport himself didn’t seem to fully grasp this point: Formal methods had an image problem. And the way to fix it wasn’t to implore programmers to change—it was to change yourself. Newcombe realized that to bring tools like TLA+ to the programming mainstream, you had to start speaking their language.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">For one thing, he said that when he was introducing colleagues at Amazon to TLA+ he would avoid telling them what it stood for, because he was afraid the name made it seem unnecessarily forbidding: “Temporal Logic of Actions” has exactly the kind of highfalutin ring to it that plays well in academia, but puts off most practicing programmers. He tried also not to use the terms “formal,” “verification,” or “proof,” which reminded programmers of tedious classroom exercises. Instead, he presented TLA+ as a new kind of “pseudocode,” a stepping-stone to real code that allowed you to exhaustively test your algorithms—and that got you thinking precisely early on in the design process. “Engineers think in terms of debugging rather than ‘verification,’” he wrote, so he titled his internal talk on the subject to fellow Amazon engineers “Debugging Designs.” Rather than bemoan the fact that programmers see the world in code, Newcombe embraced it. He knew he’d lose them otherwise. “I’ve had a bunch of people say, ‘Now I get it,’” Newcombe says.</p><aside class="ArticlePullquote_root__z11cW" data-flatplan-pullquote="true">This code has created a level of complexity that is entirely new. And it has made possible a new kind of failure.</aside><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">He has since left Amazon for Oracle, where he’s been able to convince his new colleagues to give TLA+ a try. For him, using these tools is now a matter of responsibility. “We need to get better at this,” he said.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">“I’m self-taught, been coding since I was nine, so my instincts were to start coding. That was my only—that was my way of thinking: You’d sketch something, try something, you’d organically evolve it.” In his view, this is what many programmers today still do. “They google, and they look on Stack Overflow” (a popular website where programmers answer each other’s technical questions) “and they get snippets of code to solve their tactical concern in this little function, and they glue it together, and iterate.”</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">“And that’s completely fine until you run smack into a real problem.”</p><p class="ArticleParagraph_root__4mszW ArticleParagraph_dropcap__uIVzg" data-flatplan-paragraph="true" data-flatplan-dropcap="true">I<span class="smallcaps">n the summer</span> of 2015, a pair of American security researchers, Charlie Miller and Chris Valasek, convinced that car manufacturers weren’t taking software flaws seriously enough, demonstrated that a 2014 Jeep Cherokee could be remotely controlled by hackers. They took advantage of the fact that the car’s entertainment system, which has a cellular connection (so that, for instance, you can start your car with your iPhone), was connected to more central systems, like the one that controls the windshield wipers, steering, acceleration, and brakes (so that, for instance, you can see guidelines on the rearview screen that respond as you turn the wheel). As proof of their attack, which they developed on nights and weekends, they hacked into Miller’s car while a journalist was driving it on the highway, and made it go haywire; the journalist, who knew what was coming, panicked when they cut the engines, forcing him to a slow crawl on a stretch of road with no shoulder to escape to.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">Although they didn’t actually create one, they showed that it was possible to write a clever piece of software, a “vehicle worm,” that would use the onboard computer of a hacked Jeep Cherokee to scan for and hack others; had they wanted to, they could have had simultaneous access to a nationwide fleet of vulnerable cars and SUVs. (There were at least five Fiat Chrysler models affected, including the Jeep Cherokee.) One day they could have told them all to, say, suddenly veer left or cut the engines at high speed.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">“We need to think about software differently,” Valasek told me. Car companies have long assembled their final product from parts made by hundreds of different suppliers. But where those parts were once purely mechanical, they now, as often as not, come with millions of lines of code. And while some of this code—for adaptive cruise control, for auto braking and lane assist—has indeed made cars safer (“The safety features on my Jeep have already saved me countless times,” says Miller), it has also created a level of complexity that is entirely new. And it has made possible a new kind of failure.</p><aside class="ArticlePullquote_root__z11cW" data-flatplan-pullquote="true">In the world of the self-driving car, software can’t be an afterthought.</aside><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">“There are lots of bugs in cars,” Gerard Berry, the French researcher behind Esterel, said in a talk. “It’s not like avionics—in avionics it’s taken very seriously. And it’s admitted that software is different from mechanics.” The automotive industry is perhaps among those that haven’t yet realized they are actually in the software business.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">“We don’t in the automaker industry have a regulator for software safety that knows what it’s doing,” says Michael Barr, the software expert who testified in the Toyota case. NHTSA, he says, “has only limited software expertise. They’ve come at this from a mechanical history.” The same regulatory pressures that have made model-based design and code generation attractive to the aviation industry have been slower to come to car manufacturing. Emmanuel Ledinot, of Dassault Aviation, speculates that there might be economic reasons for the difference, too. Automakers simply can’t afford to increase the price of a component by even a few cents, since it is multiplied so many millionfold; the computers embedded in cars therefore have to be slimmed down to the bare minimum, with little room to run code that hasn’t been hand-tuned to be as lean as possible. “Introducing model-based software development was, I think, for the last decade, too costly for them.”</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">One suspects the incentives are changing. “I think the autonomous car might push them,” Ledinot told me—“ISO 26262 and the autonomous car might slowly push them to adopt this kind of approach on critical parts.” (ISO 26262 is a safety standard for cars published in 2011.) Barr said much the same thing: In the world of the self-driving car, software can’t be an afterthought. It can’t be built like today’s airline-reservation systems or 911 systems or stock-trading systems. Code will be put in charge of hundreds of millions of lives on the road and it has to work. That is no small task.</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">“Computing is fundamentally invisible,” Gerard Berry said in his talk. “When your tires are flat, you look at your tires, they are flat. When your software is broken, you look at your software, you see nothing.”</p><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true">“So that’s a big problem.”</p><hr class="ArticleLegacyHtml_root__WFd2I ArticleLegacyHtml_standard__kC_zi"/><p class="ArticleParagraph_root__4mszW" data-flatplan-paragraph="true"><small><a data-event-element="inline link" id="Correction" name="Correction"></a><a data-event-element="inline link" href="#Key%20Tasks">*</a> <em>This article originally stated that there were 10 million ways for the Toyota Camry to cause unintended acceleration. We regret the error.</em></small></p><div class="ArticleBody_divider__GpNxD" id="article-end"></div></section></div><div data-event-module="footer"><div class="ArticleWell_root__fueCa"><div data-event-module="author footer" class="ArticleFooter_authorFooter__5NsdY"><div class="SectionHeading_root__3GnqT"><h3 class="SectionHeading_heading__iNkek">About the Author</h3></div><div class="ArticleBio_root__ua8zj"><address id="article-writer-0" class="ArticleBio_author__6pDyl" data-event-element="author" data-event-position="1"><div class="ArticleBio_content__O0ZVF"><div class="ArticleBio_topContainer__QYRU4"><a class="ArticleBio_headshotContainer__Am2nR" href="https://www.theatlantic.com/author/james-somers/" data-event-element="image" aria-label="Read more by James Somers"><img alt="" loading="lazy" class="Image_root__XxsOp Image_lazy__hYWHV ArticleBio_headshot__6Aykd" src="https://cdn.theatlantic.com/thumbor/dAWiCuHMQIN5yuJ84kZJUGUhIUY=/32x556:3000x3524/120x120/media/None/headshot-15/original.jpg" width="60" height="60"/></a><div><div class="ArticleBio_bioNameMulti__gvg_b"><a href="https://www.theatlantic.com/author/james-somers/" data-event-element="author name">James Somers</a></div></div></div><div class="ArticleBio_bioSection__Hef4P"><div class="ArticleBio_bioSection__Hef4P" data-flatplan-bio="true"><a href="https://www.theatlantic.com/author/james-somers/" class="author-link" data-label="https://www.theatlantic.com/author/james-somers/" data-action="click author - name" >James Somers</a> is a former contributing editor at <em>The Atlantic</em>.</div></div></div></address></div></div></div></div><gpt-ad class="GptAd_root__pAvcS ArticleInjector_root__I7x9v s-native s-native--standard s-native--streamline article-injector-ad ad-injector-most-popular" format="injector" sizes-at-0="mobile-wide,native,house" targeting-pos="injector-most-popular" sizes-at-976="desktop-wide,native,house"></gpt-ad></article><div></div></main><div></div><footer class="Footer_root__9UmiB"><nav class="Footer_container__w17O5 Footer_topContainer__fhwy3" aria-labelledby="footer-top-title"><h2 class="Footer_visuallyHidden__vz2H2" id="footer-top-title">Popular Links</h2><ul class="Footer_topContentDesktop__VMaZL Footer_list__IW19i"><li><h3 class="Footer_desktopHeader__3QUwp">About</h3><ul class="Footer_list__IW19i"><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="https://www.theatlantic.com/history/">Our History</a></li><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="https://www.theatlantic.com/jobs/">Careers</a></li></ul></li><li><h3 class="Footer_desktopHeader__3QUwp">Contact</h3><ul class="Footer_list__IW19i"><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="https://support.theatlantic.com/">Help Center</a></li><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="https://www.theatlantic.com/contact/">Contact Us</a></li><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="https://www.theatlantic.com/advertising/">Atlantic Advertising</a></li><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="/press-releases/">Press</a></li><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="https://support.theatlantic.com/hc/en-us/articles/360049974014-Permissions-to-reprint-or-reproduce-content-from-The-Atlantic">Reprints &amp; Permissions</a></li></ul></li><li><h3 class="Footer_desktopHeader__3QUwp">Podcasts</h3><ul class="Footer_list__IW19i"><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="/podcasts/radio-atlantic/">Radio Atlantic</a></li><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="/podcasts/the-david-frum-show/">The David Frum Show</a></li><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="/podcasts/galaxy-brain/">Galaxy Brain</a></li><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="/podcasts/autocracy-in-america/">Autocracy in America</a></li><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="/podcasts/how-to-build-a-happy-life/">How to Touch Grass</a></li></ul></li><li><h3 class="Footer_desktopHeader__3QUwp">Subscription</h3><ul class="Footer_list__IW19i"><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="https://www.theatlantic.com/subscribe/footer-cover/">Purchase</a></li><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="https://www.theatlantic.com/subscribe/footer-gift/">Give a Gift</a></li><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="https://accounts.theatlantic.com">Manage Subscription</a></li><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="https://www.theatlantic.com/group-subscriptions/">Group Subscriptions</a></li><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="https://www.theatlantic.com/atlantic-editions/">Atlantic Editions</a></li><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="/newsletters/">Newsletters</a></li></ul></li><li><h3 class="Footer_desktopHeader__3QUwp">Follow</h3><ul class="Footer_list__IW19i Footer_follow__J4j_g Footer_followDesktop__fP46_"><li class="Footer_followItem__lPsSq"><a href="https://www.facebook.com/TheAtlantic" class="Footer_link__APtuh" target="_blank" rel="noopener noreferrer nofollow"><svg viewBox="0 0 16 16" class="Footer_icon__h_v7e"><title>facebook</title><path d="M15.117 0H.883A.883.883 0 000 .883v14.234c0 .488.395.883.883.883h7.663V9.804H6.461V7.389h2.085V5.61c0-2.067 1.262-3.192 3.106-3.192.883 0 1.642.065 1.863.095v2.16h-1.279c-1.002 0-1.196.476-1.196 1.176V7.39h2.39l-.31 2.415h-2.08V16h4.077a.883.883 0 00.883-.883V.883A.883.883 0 0015.117 0" fill-rule="evenodd"></path></svg></a></li><li class="Footer_followItem__lPsSq Footer_alignCenter__ETIBA"><a href="https://www.instagram.com/theatlantic" class="Footer_link__APtuh" target="_blank" rel="noopener noreferrer nofollow"><svg viewBox="0 0 16 16" class="Footer_icon__h_v7e"><title>instagram</title><path d="M8 0C5.827 0 5.555.01 4.702.048 3.85.087 3.269.222 2.76.42a3.921 3.921 0 00-1.417.923A3.9 3.9 0 00.42 2.76C.222 3.269.087 3.85.048 4.702.01 5.555 0 5.827 0 8s.01 2.445.048 3.298c.039.852.174 1.433.372 1.942.204.526.478.973.923 1.417a3.9 3.9 0 001.417.923c.509.198 1.09.333 1.942.372C5.555 15.99 5.827 16 8 16s2.445-.01 3.298-.048c.852-.039 1.433-.174 1.942-.372a3.921 3.921 0 001.417-.923 3.9 3.9 0 00.923-1.417c.198-.509.333-1.09.372-1.942C15.99 10.445 16 10.173 16 8s-.01-2.445-.048-3.298c-.039-.852-.174-1.433-.372-1.942a3.921 3.921 0 00-.923-1.417A3.921 3.921 0 0013.24.42c-.509-.198-1.09-.333-1.942-.372C10.445.01 10.173 0 8 0zm0 1.442c2.136 0 2.39.008 3.233.046.78.036 1.203.166 1.485.276.374.145.64.318.92.598.28.28.453.546.598.92.11.282.24.705.276 1.485.038.844.046 1.097.046 3.233s-.008 2.39-.046 3.233c-.036.78-.166 1.203-.276 1.485-.145.374-.318.64-.598.92-.28.28-.546.453-.92.598-.282.11-.705.24-1.485.276-.844.038-1.097.047-3.233.047s-2.39-.009-3.233-.047c-.78-.036-1.203-.166-1.485-.276a2.478 2.478 0 01-.92-.598 2.478 2.478 0 01-.598-.92c-.11-.282-.24-.705-.276-1.485-.038-.844-.047-1.097-.047-3.233s.009-2.39.047-3.233c.036-.78.166-1.203.276-1.485.145-.374.318-.64.598-.92.28-.28.546-.453.92-.598.282-.11.705-.24 1.485-.276.844-.038 1.097-.046 3.233-.046zM7.9 3.8a4.1 4.1 0 100 8.2 4.1 4.1 0 000-8.2zm0 6.761a2.661 2.661 0 110-5.322 2.661 2.661 0 010 5.322zM13.4 3.8a1 1 0 11-2 0 1 1 0 012 0z" fill-rule="evenodd"></path></svg></a></li><li class="Footer_followItem__lPsSq Footer_alignRight__tNXmJ"><a href="https://www.youtube.com/user/TheAtlantic" class="Footer_link__APtuh" target="_blank" rel="noopener noreferrer nofollow"><svg viewBox="0 0 16 12" class="Footer_icon__h_v7e"><title>youtube</title><path d="M11.428 6a.589.589 0 01-.267.506l-4.572 3a.508.508 0 01-.303.094.585.585 0 01-.277-.075A.613.613 0 015.714 9V3c0-.216.116-.422.295-.525a.542.542 0 01.58.019l4.572 3c.17.103.268.3.268.506zM16 6c0-1.34 0-2.766-.277-4.069-.196-.919-.893-1.594-1.732-1.697C12.01 0 10 0 8 0 6 0 3.991 0 2.009.234 1.169.338.482 1.013.286 1.931 0 3.234 0 4.66 0 6c0 1.34 0 2.766.277 4.069.196.919.893 1.594 1.732 1.697C3.99 12 6 12 8 12c2 0 4.009 0 5.991-.234.84-.104 1.536-.779 1.723-1.697C16 8.766 16 7.34 16 6z" fill-rule="evenodd"></path></svg></a></li><li class="Footer_followItem__lPsSq"><a href="https://twitter.com/TheAtlantic" class="Footer_link__APtuh" target="_blank" rel="noopener noreferrer nofollow"><svg viewBox="0 0 20 20" fill="none" xmlns="http://www.w3.org/2000/svg" class="Footer_icon__h_v7e"><title>twitter</title><path d="M2.038 2.51l6.178 8.262L2 17.49h1.4l5.442-5.88 4.397 5.88H18l-6.525-8.726 5.786-6.252h-1.399L10.85 7.927 6.8 2.51H2.039zm2.058 1.031h2.186l9.659 12.918h-2.187L4.096 3.54z" fill="#fff"></path></svg></a></li><li class="Footer_followItem__lPsSq Footer_alignCenter__ETIBA"><a href="https://www.linkedin.com/company/the-atlantic" class="Footer_link__APtuh" target="_blank" rel="noopener noreferrer nofollow"><svg viewBox="0 0 16 16" class="Footer_icon__h_v7e"><title>linkedin</title><path d="M3.502 15.925H.343V5.085h3.09v10.84h.07zM1.854 3.738C.687 3.738 0 2.916 0 1.87 0 .822.755 0 1.923 0 3.09 0 3.777.822 3.777 1.87c0 .971-.756 1.868-1.923 1.868zM16 15.925h-3.57v-5.607c0-1.496-.55-2.468-1.786-2.468-.962 0-1.442.673-1.717 1.346-.069.225-.069.598-.069.897V16H5.356s.069-9.944 0-10.916h3.502v1.72c.206-.748 1.305-1.795 3.09-1.795 2.198 0 3.983 1.57 3.983 4.935v5.981H16z" fill-rule="evenodd"></path></svg></a></li><li class="Footer_followItem__lPsSq Footer_alignRight__tNXmJ"><a href="https://flipboard.com/@theatlantic" class="Footer_link__APtuh" target="_blank" rel="noopener noreferrer nofollow"><svg viewBox="0 0 500 500" class="Footer_icon__h_v7e"><title>flipboard</title><path d="M0 0v500h500V0H0zm400 200H300v100H200v100H100V100h300v100z"></path></svg></a></li></ul></li></ul><div class="Footer_topContentAccordion__rTbB7" data-reach-accordion=""><div class="Footer_accordionItem__1Y5Bg" data-reach-accordion-item="" data-state="collapsed"><h3 class="Footer_accordionHeader__tKhwC"><button aria-controls="panel--:Rdlim:---1" aria-expanded="false" class="Footer_accordionButton__C6Aza" data-reach-accordion-button="" data-state="collapsed" id="button--:Rdlim:---1">About</button></h3><div hidden="" role="region" aria-labelledby="button--:Rdlim:---1" class="Footer_accordionPanel__FYH2G" data-reach-accordion-panel="" data-state="collapsed" id="panel--:Rdlim:---1"><ul class="Footer_list__IW19i"><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="https://www.theatlantic.com/history/">Our History</a></li><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="https://www.theatlantic.com/jobs/">Careers</a></li></ul></div></div><div class="Footer_accordionItem__1Y5Bg" data-reach-accordion-item="" data-state="collapsed"><h3 class="Footer_accordionHeader__tKhwC"><button aria-controls="panel--:Rdlim:---1" aria-expanded="false" class="Footer_accordionButton__C6Aza" data-reach-accordion-button="" data-state="collapsed" id="button--:Rdlim:---1">Contact</button></h3><div hidden="" role="region" aria-labelledby="button--:Rdlim:---1" class="Footer_accordionPanel__FYH2G" data-reach-accordion-panel="" data-state="collapsed" id="panel--:Rdlim:---1"><ul class="Footer_list__IW19i"><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="https://support.theatlantic.com/">Help Center</a></li><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="https://www.theatlantic.com/contact/">Contact Us</a></li><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="https://www.theatlantic.com/advertising/">Atlantic Advertising</a></li><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="/press-releases/">Press</a></li><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="https://support.theatlantic.com/hc/en-us/articles/360049974014-Permissions-to-reprint-or-reproduce-content-from-The-Atlantic">Reprints &amp; Permissions</a></li></ul></div></div><div class="Footer_accordionItem__1Y5Bg" data-reach-accordion-item="" data-state="collapsed"><h3 class="Footer_accordionHeader__tKhwC"><button aria-controls="panel--:Rdlim:---1" aria-expanded="false" class="Footer_accordionButton__C6Aza" data-reach-accordion-button="" data-state="collapsed" id="button--:Rdlim:---1">Podcasts</button></h3><div hidden="" role="region" aria-labelledby="button--:Rdlim:---1" class="Footer_accordionPanel__FYH2G" data-reach-accordion-panel="" data-state="collapsed" id="panel--:Rdlim:---1"><ul class="Footer_list__IW19i"><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="/podcasts/radio-atlantic/">Radio Atlantic</a></li><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="/podcasts/the-david-frum-show/">The David Frum Show</a></li><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="/podcasts/galaxy-brain/">Galaxy Brain</a></li><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="/podcasts/autocracy-in-america/">Autocracy in America</a></li><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="/podcasts/how-to-build-a-happy-life/">How to Touch Grass</a></li></ul></div></div><div class="Footer_accordionItem__1Y5Bg" data-reach-accordion-item="" data-state="collapsed"><h3 class="Footer_accordionHeader__tKhwC"><button aria-controls="panel--:Rdlim:---1" aria-expanded="false" class="Footer_accordionButton__C6Aza" data-reach-accordion-button="" data-state="collapsed" id="button--:Rdlim:---1">Subscription</button></h3><div hidden="" role="region" aria-labelledby="button--:Rdlim:---1" class="Footer_accordionPanel__FYH2G" data-reach-accordion-panel="" data-state="collapsed" id="panel--:Rdlim:---1"><ul class="Footer_list__IW19i"><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="https://www.theatlantic.com/subscribe/footer-cover/">Purchase</a></li><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="https://www.theatlantic.com/subscribe/footer-gift/">Give a Gift</a></li><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="https://accounts.theatlantic.com">Manage Subscription</a></li><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="https://www.theatlantic.com/group-subscriptions/">Group Subscriptions</a></li><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="https://www.theatlantic.com/atlantic-editions/">Atlantic Editions</a></li><li class="Footer_topListItem__lYrM2"><a class="Footer_link__APtuh" href="/newsletters/">Newsletters</a></li></ul></div></div><div class="Footer_accordionItem__1Y5Bg" data-reach-accordion-item="" data-state="collapsed"><h3 class="Footer_accordionHeader__tKhwC"><button aria-controls="panel--:Rdlim:---1" aria-expanded="false" class="Footer_accordionButton__C6Aza" data-reach-accordion-button="" data-state="collapsed" id="button--:Rdlim:---1">Follow</button></h3><div hidden="" role="region" aria-labelledby="button--:Rdlim:---1" class="Footer_accordionPanel__FYH2G" data-reach-accordion-panel="" data-state="collapsed" id="panel--:Rdlim:---1"><ul class="Footer_list__IW19i Footer_follow__J4j_g"><li class="Footer_followItem__lPsSq"><a href="https://www.facebook.com/TheAtlantic" class="Footer_link__APtuh" target="_blank" rel="noopener noreferrer nofollow"><svg viewBox="0 0 16 16" class="Footer_icon__h_v7e"><title>facebook</title><path d="M15.117 0H.883A.883.883 0 000 .883v14.234c0 .488.395.883.883.883h7.663V9.804H6.461V7.389h2.085V5.61c0-2.067 1.262-3.192 3.106-3.192.883 0 1.642.065 1.863.095v2.16h-1.279c-1.002 0-1.196.476-1.196 1.176V7.39h2.39l-.31 2.415h-2.08V16h4.077a.883.883 0 00.883-.883V.883A.883.883 0 0015.117 0" fill-rule="evenodd"></path></svg></a></li><li class="Footer_followItem__lPsSq Footer_alignCenter__ETIBA"><a href="https://www.instagram.com/theatlantic" class="Footer_link__APtuh" target="_blank" rel="noopener noreferrer nofollow"><svg viewBox="0 0 16 16" class="Footer_icon__h_v7e"><title>instagram</title><path d="M8 0C5.827 0 5.555.01 4.702.048 3.85.087 3.269.222 2.76.42a3.921 3.921 0 00-1.417.923A3.9 3.9 0 00.42 2.76C.222 3.269.087 3.85.048 4.702.01 5.555 0 5.827 0 8s.01 2.445.048 3.298c.039.852.174 1.433.372 1.942.204.526.478.973.923 1.417a3.9 3.9 0 001.417.923c.509.198 1.09.333 1.942.372C5.555 15.99 5.827 16 8 16s2.445-.01 3.298-.048c.852-.039 1.433-.174 1.942-.372a3.921 3.921 0 001.417-.923 3.9 3.9 0 00.923-1.417c.198-.509.333-1.09.372-1.942C15.99 10.445 16 10.173 16 8s-.01-2.445-.048-3.298c-.039-.852-.174-1.433-.372-1.942a3.921 3.921 0 00-.923-1.417A3.921 3.921 0 0013.24.42c-.509-.198-1.09-.333-1.942-.372C10.445.01 10.173 0 8 0zm0 1.442c2.136 0 2.39.008 3.233.046.78.036 1.203.166 1.485.276.374.145.64.318.92.598.28.28.453.546.598.92.11.282.24.705.276 1.485.038.844.046 1.097.046 3.233s-.008 2.39-.046 3.233c-.036.78-.166 1.203-.276 1.485-.145.374-.318.64-.598.92-.28.28-.546.453-.92.598-.282.11-.705.24-1.485.276-.844.038-1.097.047-3.233.047s-2.39-.009-3.233-.047c-.78-.036-1.203-.166-1.485-.276a2.478 2.478 0 01-.92-.598 2.478 2.478 0 01-.598-.92c-.11-.282-.24-.705-.276-1.485-.038-.844-.047-1.097-.047-3.233s.009-2.39.047-3.233c.036-.78.166-1.203.276-1.485.145-.374.318-.64.598-.92.28-.28.546-.453.92-.598.282-.11.705-.24 1.485-.276.844-.038 1.097-.046 3.233-.046zM7.9 3.8a4.1 4.1 0 100 8.2 4.1 4.1 0 000-8.2zm0 6.761a2.661 2.661 0 110-5.322 2.661 2.661 0 010 5.322zM13.4 3.8a1 1 0 11-2 0 1 1 0 012 0z" fill-rule="evenodd"></path></svg></a></li><li class="Footer_followItem__lPsSq Footer_alignRight__tNXmJ"><a href="https://www.youtube.com/user/TheAtlantic" class="Footer_link__APtuh" target="_blank" rel="noopener noreferrer nofollow"><svg viewBox="0 0 16 12" class="Footer_icon__h_v7e"><title>youtube</title><path d="M11.428 6a.589.589 0 01-.267.506l-4.572 3a.508.508 0 01-.303.094.585.585 0 01-.277-.075A.613.613 0 015.714 9V3c0-.216.116-.422.295-.525a.542.542 0 01.58.019l4.572 3c.17.103.268.3.268.506zM16 6c0-1.34 0-2.766-.277-4.069-.196-.919-.893-1.594-1.732-1.697C12.01 0 10 0 8 0 6 0 3.991 0 2.009.234 1.169.338.482 1.013.286 1.931 0 3.234 0 4.66 0 6c0 1.34 0 2.766.277 4.069.196.919.893 1.594 1.732 1.697C3.99 12 6 12 8 12c2 0 4.009 0 5.991-.234.84-.104 1.536-.779 1.723-1.697C16 8.766 16 7.34 16 6z" fill-rule="evenodd"></path></svg></a></li><li class="Footer_followItem__lPsSq"><a href="https://twitter.com/TheAtlantic" class="Footer_link__APtuh" target="_blank" rel="noopener noreferrer nofollow"><svg viewBox="0 0 20 20" fill="none" xmlns="http://www.w3.org/2000/svg" class="Footer_icon__h_v7e"><title>twitter</title><path d="M2.038 2.51l6.178 8.262L2 17.49h1.4l5.442-5.88 4.397 5.88H18l-6.525-8.726 5.786-6.252h-1.399L10.85 7.927 6.8 2.51H2.039zm2.058 1.031h2.186l9.659 12.918h-2.187L4.096 3.54z" fill="#fff"></path></svg></a></li><li class="Footer_followItem__lPsSq Footer_alignCenter__ETIBA"><a href="https://www.linkedin.com/company/the-atlantic" class="Footer_link__APtuh" target="_blank" rel="noopener noreferrer nofollow"><svg viewBox="0 0 16 16" class="Footer_icon__h_v7e"><title>linkedin</title><path d="M3.502 15.925H.343V5.085h3.09v10.84h.07zM1.854 3.738C.687 3.738 0 2.916 0 1.87 0 .822.755 0 1.923 0 3.09 0 3.777.822 3.777 1.87c0 .971-.756 1.868-1.923 1.868zM16 15.925h-3.57v-5.607c0-1.496-.55-2.468-1.786-2.468-.962 0-1.442.673-1.717 1.346-.069.225-.069.598-.069.897V16H5.356s.069-9.944 0-10.916h3.502v1.72c.206-.748 1.305-1.795 3.09-1.795 2.198 0 3.983 1.57 3.983 4.935v5.981H16z" fill-rule="evenodd"></path></svg></a></li><li class="Footer_followItem__lPsSq Footer_alignRight__tNXmJ"><a href="https://flipboard.com/@theatlantic" class="Footer_link__APtuh" target="_blank" rel="noopener noreferrer nofollow"><svg viewBox="0 0 500 500" class="Footer_icon__h_v7e"><title>flipboard</title><path d="M0 0v500h500V0H0zm400 200H300v100H200v100H100V100h300v100z"></path></svg></a></li></ul></div></div></div></nav><nav class="Footer_container__w17O5 Footer_bottomContainer__oTVst" aria-labelledby="footer-bottom-title"><h2 class="Footer_visuallyHidden__vz2H2" id="footer-bottom-title">Site Information</h2><div class="Footer_bottomContent__d4897"><ul class="Footer_list__IW19i"><li class="Footer_bottomListItem__6oLZ_"><a class="Footer_link__APtuh" href="https://www.theatlantic.com/privacy-policy/">Privacy Policy</a></li><li class="Footer_bottomListItem__6oLZ_"><a class="Footer_link__APtuh" href="https://www.theatlantic.com/do-not-sell-my-personal-information/">Your Privacy Choices<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 30 14" class="Footer_iconBottom__jKayV"><title>privacy-options</title><path d="M22.6 0H7.4c-3.9 0-7 3.1-7 7s3.1 7 7 7h15.2c3.9 0 7-3.1 7-7s-3.2-7-7-7zm-8.4 12.8H7.4c-3.2 0-5.8-2.6-5.8-5.8s2.6-5.8 5.8-5.8h9.9l-3.1 11.6zM24.7 10c-.2.2-.6.2-.8 0l-2.2-2.2-2.2 2.2c-.2.2-.6.2-.8 0s-.2-.6 0-.8L20.8 7l-2.2-2.2c-.2-.2-.2-.6 0-.8.2-.2.6-.2.8 0l2.2 2.2L23.8 4c.2-.2.6-.2.8 0 .2.2.2.6 0 .8L22.5 7l2.2 2.2c.2.2.2.6 0 .8z"></path><path d="M5.4 6.9c-.2.2-.2.6 0 .8l2.2 2.2c.2.2.5.2.7 0l4.5-5.1c.2-.2.2-.6 0-.8s-.7-.2-.9 0L8.1 8.5 6.3 6.8c-.2-.2-.6-.2-.8 0z"></path></svg></a></li><li class="Footer_bottomListItem__6oLZ_"><a class="Footer_link__APtuh" href="https://www.theatlantic.com/advertising-guidelines/">Advertising Guidelines</a></li><li class="Footer_bottomListItem__6oLZ_"><a class="Footer_link__APtuh" href="https://www.theatlantic.com/terms-and-conditions/">Terms &amp; Conditions</a></li><li class="Footer_bottomListItem__6oLZ_"><a class="Footer_link__APtuh" href="https://www.theatlantic.com/terms-of-sale/">Terms of Sale</a></li><li class="Footer_bottomListItem__6oLZ_"><a class="Footer_link__APtuh" href="https://www.theatlantic.com/responsible-disclosure-policy/">Responsible Disclosure</a></li><li class="Footer_bottomListItem__6oLZ_"><a class="Footer_link__APtuh" href="/site-map/">Site Map</a></li></ul><div id="privacy-link"></div><p class="Footer_copyright__AIyiF">TheAtlantic.com © <!-- -->2026<!-- --> The Atlantic Monthly Group. All Rights Reserved.</p><p class="Footer_disclaimer__aeAcq">This site is protected by reCAPTCHA and the Google<!-- --> <a class="Footer_link__APtuh" href="https://policies.google.com/privacy">Privacy Policy</a> <!-- -->and<!-- --> <a class="Footer_link__APtuh" href="https://policies.google.com/terms">Terms of Service</a> <!-- -->apply</p></div><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 214 33.24" class="Footer_logo__gR__n" role="img" aria-label="The Atlantic"><path d="M39.39 13.2c-2.4 0-4.43 1.82-7 5.32-1.18 1.64-2.7 4-3.37 5-.38.51-.68.43-.47-.12l1.78-4.56 6.36-17.5C37 .62 34.46-.25 34 .62v.09c-1.09 2.32-3.12 3.08-6.75 2.95S16.32 1.52 10.8 1.52C3.88 1.52 0 5.78 0 10.8c0 2.82 1.85 4.64 4.34 4.55a2.27 2.27 0 002.41-1.81 1.2 1.2 0 00-1.56-1.43c-2.45.51-3.29-1.18-3.29-2.49 0-3.12 2.66-5.44 8.22-5.44 1.43 0 4.22.34 7.17.67-3.75 11.3-7.55 21.77-8.48 24.25a2.07 2.07 0 01-1.35 1.44c-1.34.42-1.77.46-2.61.67-1.27.3-1.06 1.35-.17 1.31 1.6-.09 3.67-.3 5.31-.3 2 0 5.61.17 6.16.21 1 .09 1.14-1.14.3-1.26-.59-.09-1.56-.25-2.49-.38-1.1-.13-1.43-.59-1.18-1.48.55-1.47 7-20.11 8.27-24 2 .25 3.71.42 4.84.5 2.33.14 4.57 0 6.5-1.41l-5.1 14.4-4.47 12.33c-.76 2 2.1 2.15 2.74.93a81.64 81.64 0 017.63-12.36c1.86-2.7 3.59-4.31 4.81-4.31.93 0 1.47.51 1.47 1.65 0 1.52-.71 3.88-2.15 7.89-1.89 5.23-2.61 6.62-3.24 6.66s-1.86-1.52-2.53-1.69a1.39 1.39 0 00-1.65.72c-.34.59-.12 2.49 2.74 2.62 3.42.16 6.33-3.34 8.35-8.94 1.39-3.8 1.73-5.74 1.73-7.13 0-2.7-1.26-3.97-3.33-3.97zm57.9 18.09c-2.15-.5-3-1.3-3-2.15l.09-1.77c0-1.3 1-20.49 1.22-23.36.17-2.11-2.24-2-3.25-.76l-2 2.57C87.89 8.9 78 21.68 73.17 27.67A11.5 11.5 0 0168 31.25c-.8.21-.72 1.06.17 1.06.71 0 2.82-.25 4.38-.25s4.43.12 5.15.16 1-.76 0-1c-2-.59-3-1-3-1.52s.46-1.22 1.56-2.74c.84-1.18 2.86-3.84 5.1-6.79H91c-.21 4.05-.46 8.31-.5 9.15a1.14 1.14 0 01-.93 1.14l-2.15.63c-.59.17-.85 1.27.08 1.23 2.11-.13 3.88-.3 4.81-.3 1.39 0 3.75.3 4.85.34s.94-.85.13-1.07zm-6-15.47c0 .76-.09 1.6-.13 2.49h-8.25c3.84-5.07 7.89-10.38 8.23-10.89s.67-.25.63.13c-.13 1.86-.34 5.27-.5 8.27zM55.08 13.5c-3.67-.17-7.76 4.09-9.7 10.5-1.9 6.2.21 8.77 2.53 8.77 1.69 0 4.51-2.19 6.07-4.72.55-.89.13-1.82-.71-.89-1.06 1.14-2.49 2.36-4 2.07-1-.17-1.94-1.9-.46-6.2 3.54-.17 7.71-2.19 8.77-5.53.92-2.88-.98-3.96-2.5-4zm.38 3.12c-.89 2.61-4 4.8-6.24 5.35 2.15-5.69 4.21-7.21 5.52-7.17.72 0 1.06.82.72 1.82zm53.94-1h3.42c.76 0 1.14-.21 1.3-.76.3-.72.13-1.06-.63-1.06h-3.42l1.65-4.38c.21-.59 0-.89-.34-.89h-1.77c-.46 0-.63.13-.84.72L107 13.83h-2.7c-.38 0-.68-.08-.93 1.06-.09.55 0 .76.55.76h2.4l-4.09 10.67a45.64 45.64 0 00-1.69 4.68c-.25 1.48.64 2.07 1.73 1.86 2.15-.38 5.23-2.62 8-6.12.76-1 .13-1.64-.63-.84a34.4 34.4 0 01-3.67 3.16c-1.1.72-1.64.21-1.26-.84zm38.04-1c.25-.59-.59-.76-2.53-1.13-.59-.13-.93.5-1.94 2.61a4 4 0 00-3.5-1.43c-3.08.08-6.88 2.86-10 7.12-2.49 3.42-3.25 5.78-2.78 8.31a3.11 3.11 0 003.08 2.52c2.32.08 4.64-2.11 7-4.52l1.48-1.48c.42-.42.8-.17.54.34a23.77 23.77 0 00-1.89 4.17c-.3 1.48.5 1.86 1.64 1.69 2.19-.29 5.61-2.32 8.23-5.94.75-1.06 0-1.65-.68-.85a26.62 26.62 0 01-3.75 3.29c-1.14.76-1.65.55-1.31-.34.17-.55.8-2.07 6.41-14.36zm-9.74 11c-2.66 2.45-4.81 4.22-6.29 4.22-1 0-1.47-.43-1.56-1.14-.25-1.86 1.44-4.68 2.83-6.58 2.4-3.16 5.36-5.78 7.25-5.78 1.31 0 2 .55 2.11 1.35.25 1.46-2.19 5.93-4.34 7.87zm58.58-12.71c-2.07 0-4.85 1.47-7.47 4.38-.84 1-.21 1.65.59.93a20.28 20.28 0 012.87-2.19c.89-.55 1.48-.13 1.22.67-.21.64-.84 2.2-1.3 3.25l-2.87 6.58c-.8 1.86-1.56 3.71-1.73 4.22-.38 1.31.29 2 1.35 2 2 0 4.77-1.65 7.42-4.6.84-1 .21-1.64-.59-.93a28 28 0 01-3.12 2.4c-.88.54-1.52.12-1.22-.68.21-.59.84-1.94 1.26-2.91l2.91-6.58c.85-1.94 1.82-4 2-4.55.32-1.28-.31-1.99-1.32-1.99zm2.53-10.21a2.39 2.39 0 00-2.53 2.15 2.09 2.09 0 001.85 2.45 2.43 2.43 0 002.49-2.11 2.08 2.08 0 00-1.81-2.49zm11.68 10.84c-3.71-.17-7.68 4.13-9.62 10.46s.17 8.77 2.62 8.77c1.69 0 4.51-2 6.2-4.72.55-.89.13-1.82-.72-.89-1.05 1.14-2.4 2.19-3.79 2.11s-2.37-2-.76-6.62c2.36-6.66 4-7.42 4.72-7.47s2.19 1.86 3.08 2.07a1.36 1.36 0 001.64-.71c.38-.72.14-2.83-3.37-3zm-23.95.29h-3.42l1.64-4.38c.22-.59 0-.89-.33-.89h-1.78c-.46 0-.63.13-.84.72l-1.73 4.55h-2.74c-.38 0-.67-.08-.93 1.06-.08.55.05.76.55.76h2.41l-4.09 10.67a43.34 43.34 0 00-1.69 4.68c-.26 1.48.63 2.07 1.73 1.86 2.15-.38 5.23-2.62 8-6.12.76-1 .13-1.64-.64-.84a34.33 34.33 0 01-3.68 3.16c-1.1.72-1.65.21-1.27-.84l4.71-12.6h3.42c.76 0 1.14-.21 1.31-.76.29-.69.12-1.03-.63-1.03zm-63.6 11.9a40.24 40.24 0 01-3.8 3.33c-1.1.72-1.64.21-1.26-.84L128.17.97c.17-.42.08-1-.51-1a58.6 58.6 0 00-6 .68c-.34.08-.51.59-.13.71l2.28.85c.46.17.51.38.21 1.14l-8.84 22.97a43.34 43.34 0 00-1.69 4.68c-.25 1.48.63 2.07 1.73 1.86 2.28-.38 5.52-2.62 8.35-6.29.76-1.01.13-1.64-.63-.84zm43.39.08l2.49-5c1.35-2.74 1.61-4 1.61-4.93 0-1.81-.93-2.74-2.83-2.74-2.66 0-4.77 2.11-8 6.66-.89 1.22-1.48 2.15-2.66 3.67-.38.47-.67.42-.46-.13l1.64-4.09a17 17 0 001.35-4.47c0-1.09-.46-1.6-1.64-1.6-1.44 0-3.25.76-6.41 4.77-1.14 1.47 0 1.64.38 1.18.63-.64 2-2.07 2.91-2.87s1.72-.55 1.39.42a18.36 18.36 0 01-.8 2.24l-5 12.27c-.68 1.69 2.53 2.07 3.08.8 1.73-4 5.52-9 7.08-11.22 2.28-3.25 4.26-5.48 5.69-5.48.76 0 1.1.42 1.1 1.22a5.83 5.83 0 01-.59 2l-3.54 7.55c-1 2-1.94 4.13-2.11 4.68-.42 1.31.3 2 1.43 2 2 0 4.77-1.65 7.43-4.6.84-1 .21-1.64-.59-.93a29 29 0 01-3.12 2.41c-.92.59-1.56.12-1.26-.72.21-.6.97-2.16 1.43-3.09z"></path></svg></nav></footer></div></div><script id="__NEXT_DATA__" type="application/json">{"props":{"isLoggedIn":false,"hasPaywallAccess":false,"hasAdFree":false,"pageProps":{"id":"BlogArticle:540393","isTnfCompatible":true,"layout":"feature","hasMeter":true,"url":"https://www.theatlantic.com/technology/archive/2017/09/saving-the-world-from-code/540393/","dateModified":"2017-11-16T16:26:59Z","primaryCategory":{"__typename":"Channel"},"__typename":"BlogArticle","notFound":false,"urqlState":{"741980290":{"data":"{\"article\":{\"__typename\":\"BlogArticle\"}}"},"2021745665":{"data":"{\"breakingNews\":null}"},"2317560602":{"data":"{\"recircRecommendation\":{\"displayName\":\"Recommended Reading\",\"serviceUsed\":\"datascience-control.other\",\"river\":{\"edges\":[{\"node\":{\"id\":\"BlogArticle:539193\",\"url\":\"https://www.theatlantic.com/technology/archive/2017/09/you-are-already-living-inside-a-computer/539193/\",\"title\":\"You Are Already Living Inside a Computer\",\"authors\":[{\"url\":\"https://www.theatlantic.com/author/ian-bogost/\",\"displayName\":\"Ian Bogost\",\"id\":\"Author:3000\",\"slug\":\"ian-bogost\",\"__typename\":\"Author\"}],\"riverImage\":{\"id\":\"Image:1126962:80x80:1x,2x\",\"url\":\"https://cdn.theatlantic.com/thumbor/BbAGugf5LKJ2oqsnwy7Crq5Rmnw=/333x0:1666x1333/80x80/media/img/mt/2017/09/ComputerLyfe/original.jpg\",\"srcSet\":\"https://cdn.theatlantic.com/thumbor/BbAGugf5LKJ2oqsnwy7Crq5Rmnw=/333x0:1666x1333/80x80/media/img/mt/2017/09/ComputerLyfe/original.jpg, https://cdn.theatlantic.com/thumbor/UI-2ZFSAqm79pim79M1VojtIYCo=/333x0:1666x1333/160x160/media/img/mt/2017/09/ComputerLyfe/original.jpg 2x\",\"reducedMotionSrcSet\":null,\"width\":80,\"height\":80,\"altText\":\"A person whose head has been replaced with a bulky desktop monitor\",\"__typename\":\"BasicImage\"},\"__typename\":\"BlogArticle\"},\"__typename\":\"PromoEdge\"},{\"node\":{\"id\":\"BlogArticle:406099\",\"url\":\"https://www.theatlantic.com/technology/archive/2015/09/not-even-the-people-who-write-algorithms-really-know-how-they-work/406099/\",\"title\":\"Not Even the People Who Write Algorithms Really Know How They Work\",\"authors\":[{\"url\":\"https://www.theatlantic.com/author/adrienne-lafrance/\",\"displayName\":\"Adrienne LaFrance\",\"id\":\"Author:5964\",\"slug\":\"adrienne-lafrance\",\"__typename\":\"Author\"}],\"riverImage\":{\"id\":\"Image:450556:80x80:1x,2x\",\"url\":\"https://cdn.theatlantic.com/thumbor/xX95QMYAVOjPIxXWbRKVxD1802M=/413x0:2418x2005/80x80/media/img/mt/2015/09/code/original.jpg\",\"srcSet\":\"https://cdn.theatlantic.com/thumbor/xX95QMYAVOjPIxXWbRKVxD1802M=/413x0:2418x2005/80x80/media/img/mt/2015/09/code/original.jpg, https://cdn.theatlantic.com/thumbor/TXxo92S1oBaImCawKRzCV6tvXCY=/413x0:2418x2005/160x160/media/img/mt/2015/09/code/original.jpg 2x\",\"reducedMotionSrcSet\":null,\"width\":80,\"height\":80,\"altText\":\"\",\"__typename\":\"BasicImage\"},\"__typename\":\"BlogArticle\"},\"__typename\":\"PromoEdge\"},{\"node\":{\"id\":\"MagazineArticle:617266\",\"url\":\"https://www.theatlantic.com/magazine/archive/2021/01/james-suzman-work/617266/\",\"title\":\"How Civilization Broke Our Brains\",\"authors\":[{\"url\":\"https://www.theatlantic.com/author/derek-thompson/\",\"displayName\":\"Derek Thompson\",\"id\":\"Author:1608\",\"slug\":\"derek-thompson\",\"__typename\":\"Author\"}],\"riverImage\":{\"id\":\"Image:1537013:80x80:1x,2x\",\"url\":\"https://cdn.theatlantic.com/thumbor/acUuBSvVHJDLr_yqMZUhZ4Q18Hw=/570x0:1695x1125/80x80/media/img/2020/12/CC_Thompson_Suzman/original.png\",\"srcSet\":\"https://cdn.theatlantic.com/thumbor/acUuBSvVHJDLr_yqMZUhZ4Q18Hw=/570x0:1695x1125/80x80/media/img/2020/12/CC_Thompson_Suzman/original.png, https://cdn.theatlantic.com/thumbor/G93oPVe8nQMWhPB_duXDpsAypNE=/570x0:1695x1125/160x160/media/img/2020/12/CC_Thompson_Suzman/original.png 2x\",\"reducedMotionSrcSet\":null,\"width\":80,\"height\":80,\"altText\":\"illustration of person in hammock with clouds shaped like inbox icons\",\"__typename\":\"BasicImage\"},\"__typename\":\"MagazineArticle\"},\"__typename\":\"PromoEdge\"}],\"__typename\":\"RiverConnection\"},\"__typename\":\"RecircRecommendation\"}}"},"3708086634":{"data":"{\"article\":{\"id\":\"BlogArticle:540393\",\"isTnfCompatible\":true,\"layout\":\"feature\",\"hasMeter\":true,\"url\":\"https://www.theatlantic.com/technology/archive/2017/09/saving-the-world-from-code/540393/\",\"dateModified\":\"2017-11-16T16:26:59Z\",\"primaryCategory\":{\"__typename\":\"Channel\"},\"__typename\":\"BlogArticle\"}}"},"4110843614":{"data":"{\"article\":{\"__typename\":\"BlogArticle\",\"id\":\"BlogArticle:540393\",\"authors\":[{\"url\":\"https://www.theatlantic.com/author/james-somers/\",\"displayName\":\"James Somers\",\"__typename\":\"Author\",\"id\":\"Author:2245\",\"isFollowable\":false,\"biography\":{\"default\":\"\u003ca href=\\\"https://www.theatlantic.com/author/james-somers/\\\" class=\\\"author-link\\\" data-label=\\\"https://www.theatlantic.com/author/james-somers/\\\" data-action=\\\"click author - name\\\" \u003eJames Somers\u003c/a\u003e is a former contributing editor at \u003cem\u003eThe Atlantic\u003c/em\u003e.\",\"__typename\":\"Biography\"},\"headshot\":{\"width\":120,\"height\":120,\"srcSet\":\"https://cdn.theatlantic.com/thumbor/dAWiCuHMQIN5yuJ84kZJUGUhIUY=/32x556:3000x3524/120x120/media/None/headshot-15/original.jpg, https://cdn.theatlantic.com/thumbor/-lrB4Fnu8YYU3RggS5S3L5yapmM=/32x556:3000x3524/240x240/media/None/headshot-15/original.jpg 2x\",\"url\":\"https://cdn.theatlantic.com/thumbor/dAWiCuHMQIN5yuJ84kZJUGUhIUY=/32x556:3000x3524/120x120/media/None/headshot-15/original.jpg\",\"__typename\":\"BasicImage\"},\"river\":{\"edges\":[{\"cursor\":\"MjAxOC0wNC0wNSAwODowMDowMHw1NTY2NzY=\",\"node\":{\"id\":\"BlogArticle:556676\",\"title\":\"The Scientific Paper Is Obsolete\",\"url\":\"https://www.theatlantic.com/science/archive/2018/04/the-scientific-paper-is-obsolete/556676/\",\"__typename\":\"BlogArticle\"},\"__typename\":\"PromoEdge\"},{\"cursor\":\"MjAxNy0wOS0yNiAxMToxMDo0Mnw1NDAzOTM=\",\"node\":{\"id\":\"BlogArticle:540393\",\"title\":\"The Coming Software Apocalypse\",\"url\":\"https://www.theatlantic.com/technology/archive/2017/09/saving-the-world-from-code/540393/\",\"__typename\":\"BlogArticle\"},\"__typename\":\"PromoEdge\"},{\"cursor\":\"MjAxNy0wNC0yMCAwOTo1ODoxN3w1MjMzMjA=\",\"node\":{\"id\":\"BlogArticle:523320\",\"title\":\"Torching the Modern-Day Library of Alexandria\",\"url\":\"https://www.theatlantic.com/technology/archive/2017/04/the-tragedy-of-google-books/523320/\",\"__typename\":\"BlogArticle\"},\"__typename\":\"PromoEdge\"}],\"__typename\":\"RiverConnection\"},\"slug\":\"james-somers\",\"socialMedia\":[]}],\"authorContext\":null,\"categories\":[{\"slug\":\"features\",\"__typename\":\"Category\"}],\"content\":[{\"__typename\":\"ArticleParagraphContent\",\"subtype\":\"DROPCAP\",\"idAttr\":\"\",\"innerHtml\":\"T\u003cspan class=\\\"smallcaps\\\"\u003ehere were\u003c/span\u003e six hours during the night of April 10, 2014, when the entire population of Washington State had no 911 service. People who called for help got a busy signal. One Seattle woman dialed 911 at least 37 times while a stranger was trying to break into her house. When he finally crawled into her living room through a window, she picked up a kitchen knife. The man fled.\"},{\"__typename\":\"ArticleLegacyHtml\",\"tagName\":\"P\",\"idAttr\":\"\",\"className\":\"\",\"style\":\"background-color: #333; color: #fff; padding: 12px 24px;\",\"innerHtml\":\"\u003ciframe class=\\\"lazyload\\\" data-src=\\\"https://w.soundcloud.com/player/?url=https%3A//api.soundcloud.com/tracks/346597527\u0026amp;color=%23ff5500\u0026amp;color=%23ff5500\u0026amp;inverse=true\u0026amp;auto_play=false\u0026amp;show_user=true\\\" frameborder=\\\"no\\\" height=\\\"20\\\" scrolling=\\\"no\\\" style=\\\"background-color: #333\\\" title=\\\"embedded interactive content\\\" width=\\\"100%\\\"\u003e\u003c/iframe\u003e\u003ci class=\\\"audm--download-cta\\\"\u003eTo hear more feature stories, \u003ca href=\\\"https://www.theatlantic.com/podcasts/audio-articles/?utm_source=audioarticleembed\\\" style=\\\"color: #fff; text-decoration: underline;\\\"\u003esee our full list\u003c/a\u003e or \u003ca href=\\\"https://goo.gl/ERK95W\\\" style=\\\"color: #fff; text-decoration: underline;\\\"\u003eget the Audm iPhone app.\u003c/a\u003e \u003c/i\u003e\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"The 911 outage, at the time the largest ever reported, was traced to software running on a server in Englewood, Colorado. Operated by a systems provider named Intrado, the server kept a running counter of how many calls it had routed to 911 dispatchers around the country. Intrado programmers had set a threshold for how high the counter could go. They picked a number in the millions.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"Shortly before midnight on April 10, the counter exceeded that number, resulting in chaos. Because the counter was used to generate a unique identifier for each call, new calls were rejected. And because the programmers hadn’t anticipated the problem, they hadn’t created alarms to call attention to it. Nobody knew what was happening. Dispatch centers in Washington, California, Florida, the Carolinas, and Minnesota, serving 11 million Americans, struggled to make sense of reports that callers were getting busy signals. It took until morning to realize that Intrado’s software in Englewood was responsible, and that the fix was to change a single number.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"Not long ago, emergency calls were handled locally. Outages were small and easily diagnosed and fixed. The rise of cellphones and the promise of new capabilities—what if you could text 911? or send videos to the dispatcher?—drove the development of a more complex system that relied on the internet. For the first time, there could be such a thing as a national 911 outage. There have now been four in as many years.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"It’s been said that software is “eating the world.” More and more, critical systems that were once controlled mechanically, or by people, are coming to depend on code. This was perhaps never clearer than in the summer of 2015, when on a single day, United Airlines grounded its fleet because of a problem with its departure-management system; trading was suspended on the New York Stock Exchange after an upgrade; the front page of \u003cem\u003eThe Wall Street Journal\u003c/em\u003e’s website crashed; and Seattle’s 911 system went down again, this time because a different router failed. The simultaneous failure of so many software systems smelled at first of a coordinated cyberattack. Almost more frightening was the realization, late in the day, that it was just a coincidence.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"“When we had electromechanical systems, we used to be able to test them \u003cem\u003eexhaustively\u003c/em\u003e,” says Nancy Leveson, a professor of aeronautics and astronautics at the Massachusetts Institute of Technology who has been studying software safety for 35 years. She became known for her report on the Therac-25, a radiation-therapy machine that killed six patients because of a software error. “We used to be able to think through all the things it could do, all the states it could get into.” The electromechanical interlockings that controlled train movements at railroad crossings, for instance, only had so many configurations; a few sheets of paper could describe the whole system, and you could run physical trains against each configuration to see how it would behave. Once you’d built and tested it, you knew exactly what you were dealing with.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"Software is different. Just by editing the text in a file somewhere, the same hunk of silicon can become an autopilot or an inventory-control system. This flexibility is software’s miracle, and its curse. Because it can be changed cheaply, software is constantly changed; and because it’s unmoored from anything physical—a program that is a thousand times more complex than another takes up the same actual space—it tends to grow without bound. “The problem,” Leveson wrote in a book, “is that we are attempting to build systems that are beyond our ability to intellectually manage.”\"},{\"__typename\":\"ArticlePullquote\",\"idAttr\":\"\",\"innerHtml\":\"The software did exactly what it was told to do. The reason it failed is that it was told to do the wrong thing.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"Our standard framework for thinking about engineering failures—reflected, for instance, in regulations for medical devices—was developed shortly after World War II, before the advent of software, for electromechanical systems. The idea was that you make something reliable by making its parts reliable (say, you build your engine to withstand 40,000 takeoff-and-landing cycles) and by planning for the breakdown of those parts (you have two engines). But software doesn’t \u003cem\u003ebreak\u003c/em\u003e. Intrado’s faulty threshold is not like the faulty rivet that leads to the crash of an airliner. The software did exactly what it was told to do. In fact it did it perfectly. The reason it failed is that it was told to do the wrong thing. Software failures are failures of understanding, and of imagination. Intrado actually had a backup router, which, had it been switched to automatically, would have restored 911 service almost immediately. But, as described in a report to the FCC, “the situation occurred at a point in the application logic that was not designed to perform any automated corrective actions.”\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"This is the trouble with making things out of code, as opposed to something physical. “The complexity,” as Leveson puts it, “is invisible to the eye.”\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":\"DROPCAP\",\"idAttr\":\"\",\"innerHtml\":\"T\u003cspan class=\\\"smallcaps\\\"\u003ehe attempts now\u003c/span\u003e underway to change how we make software all seem to start with the same premise: Code is too hard to think about. Before trying to understand the attempts themselves, then, it’s worth understanding why this might be: what it is about code that makes it so foreign to the mind, and so unlike anything that came before it.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"Technological progress used to change the way the world looked—you could watch the roads getting paved; you could see the skylines rise. Today you can hardly tell when something is remade, because so often it is remade by code. When you press your foot down on your car’s accelerator, for instance, you’re no longer controlling anything directly; there’s no mechanical link from the pedal to the throttle. Instead, you’re issuing a command to a piece of software that decides how much air to give the engine. The car is a computer you can sit inside of. The steering wheel and pedals might as well be keyboard keys.\"},{\"__typename\":\"ArticleRelatedContentModule\",\"contentType\":\"CURATED\",\"index\":0},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"Like everything else, the car has been computerized to enable new features. When a program is in charge of the throttle and brakes, it can slow you down when you’re too close to another car, or precisely control the fuel injection to help you save on gas. When it controls the steering, it can keep you in your lane as you start to drift, or guide you into a parking space. You couldn’t build these features without code. If you tried, a car might weigh 40,000 pounds, an immovable mass of clockwork.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"Software has enabled us to make the most intricate machines that have ever existed. And yet we have hardly noticed, because all of that complexity is packed into tiny silicon chips as millions and millions of lines of code. But just because we can’t see the complexity doesn’t mean that it has gone away.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"The programmer, the renowned Dutch computer scientist Edsger Dijkstra wrote in 1988, “has to be able to think in terms of conceptual hierarchies that are much deeper than a single mind ever needed to face before.” Dijkstra meant this as a warning. As programmers eagerly poured software into critical systems, they became, more and more, the linchpins of the built world—and Dijkstra thought they had perhaps overestimated themselves.\"},{\"__typename\":\"ArticlePullquote\",\"idAttr\":\"\",\"innerHtml\":\"“Software engineers don’t understand the \u003cem\u003eproblem\u003c/em\u003e they’re trying to solve, and don’t care to.”\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"What made programming so difficult was that it required you to think like a computer. The strangeness of it was in some sense more vivid in the early days of computing, when code took the form of literal ones and zeros. Anyone looking over a programmer’s shoulder as they pored over line after line like “100001010011” and “000010011110” would have seen just how alienated the programmer was from the actual problems they were trying to solve; it would have been impossible to tell whether they were trying to calculate artillery trajectories or simulate a game of tic-tac-toe. The introduction of programming languages like Fortran and C, which resemble English, and tools, known as “integrated development environments,” or IDEs, that help correct simple mistakes (like Microsoft Word’s grammar checker but for code), obscured, though did little to actually change, this basic alienation—the fact that the programmer didn’t work on a problem directly, but rather spent their days writing out instructions for a machine.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"“The problem is that software engineers don’t understand the \u003cem\u003eproblem\u003c/em\u003e they’re trying to solve, and don’t care to,” says Leveson, the MIT software-safety expert. The reason is that they’re too wrapped up in getting their code to work. “Software engineers like to provide all kinds of tools and stuff for coding errors,” she says, referring to IDEs. “The serious problems that have happened with software have to do with requirements, not coding errors.” When you’re writing code that controls a car’s throttle, for instance, what’s important is the rules about when and how and by how much to open it. But these systems have become so complicated that hardly anyone can keep them straight in their head. “There’s 100 million lines of code in cars now,” Leveson says. “You just cannot anticipate all these things.”\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"In September 2007, Jean Bookout was driving on the highway with her best friend in a Toyota Camry when the accelerator seemed to get stuck. When she took her foot off the pedal, the car didn’t slow down. She tried the brakes but they seemed to have lost their power. As she swerved toward an off-ramp going 50 miles per hour, she pulled the emergency brake. The car left a skid mark 150 feet long before running into an embankment by the side of the road. The passenger was killed. Bookout woke up in a hospital a month later.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"The incident was one of many in a nearly decade-long investigation into claims of so-called unintended acceleration in Toyota cars. Toyota blamed the incidents on poorly designed floor mats, “sticky” pedals, and driver error, but outsiders suspected that faulty software might be responsible. The National Highway Traffic Safety Administration enlisted software experts from NASA to perform an intensive review of Toyota’s code. After nearly 10 months, the NASA team hadn’t found evidence that software was the cause—but said they couldn’t prove it wasn’t.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"It was during litigation of the Bookout accident that someone finally found a convincing connection. Michael Barr, an expert witness for the plaintiff, had a team of software experts spend 18 months with the Toyota code, picking up where NASA left off. Barr described what they found as “spaghetti code,” programmer lingo for software that has become a tangled mess. Code turns to spaghetti when it accretes over many years, with feature after feature piling on top of, and being woven around, what’s already there; eventually the code becomes impossible to follow, let alone to test exhaustively for flaws.\"},{\"__typename\":\"ArticlePullquote\",\"idAttr\":\"\",\"innerHtml\":\"“If the software malfunctions and the same program that crashed is supposed to save the day, it can’t.”\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"\u003ca data-event-element=\\\"inline link\\\" id=\\\"Key Tasks\\\" name=\\\"Key%20Tasks\\\"\u003e\u003c/a\u003eUsing the same model as the Camry involved in the accident, Barr’s team demonstrated that there were more than 10 million ways for key tasks on the onboard computer to fail, potentially leading to unintended acceleration.\u003ca data-event-element=\\\"inline link\\\" href=\\\"#Correction\\\"\u003e*\u003c/a\u003e They showed that as little as a single bit flip—a one in the computer’s memory becoming a zero or vice versa—could make a car run out of control. The fail-safe code that Toyota had put in place wasn’t enough to stop it. “You have software watching the software,” Barr testified. “If the software malfunctions and the same program or same app that is crashed is supposed to save the day, it can’t save the day because it is not working.”\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"Barr’s testimony made the case for the plaintiff, resulting in $3 million in damages for Bookout and her friend’s family. According to \u003cem\u003eThe New York Times\u003c/em\u003e, it was the first of many similar cases against Toyota to bring to trial problems with the electronic throttle-control system, and the first time Toyota was found responsible by a jury for an accident involving unintended acceleration. The parties decided to settle the case before punitive damages could be awarded. In all, Toyota recalled more than 9 million cars, and paid nearly $3 billion in settlements and fines related to unintended acceleration.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":\"DROPCAP\",\"idAttr\":\"\",\"innerHtml\":\"T\u003cspan class=\\\"smallcaps\\\"\u003ehere will be\u003c/span\u003e more bad days for software. It's important that we get better at making it, because if we don't, and as software becomes more sophisticated and connected—as it takes control of more critical functions—those days could get worse.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"The problem is that programmers are having a hard time keeping up with their own creations. Since the 1980s, the way programmers work and the tools they use have changed remarkably little. There is a small but growing chorus that worries the status quo is unsustainable. “Even very good programmers are struggling to make sense of the systems that they are working with,” says Chris Granger, a software developer who worked as a lead at Microsoft on Visual Studio, an IDE that costs $1,199 a year and is used by nearly a third of all professional programmers. He told me that while he was at Microsoft, he arranged an end-to-end study of Visual Studio, the only one that had ever been done. For a month and a half, he watched behind a one-way mirror as people wrote code. “How do they use tools? How do they think?” he said. “How do they \u003cem\u003esit \u003c/em\u003eat the computer, do they touch the mouse, do they not touch the mouse? All these things that we have dogma around that we haven’t actually tested empirically.”\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"The findings surprised him. “Visual Studio is one of the single largest pieces of software in the world,” he said. “It’s over 55 million lines of code. And one of the things that I found out in this study is more than 98 percent of it is completely irrelevant. All this work had been put into this thing, but it missed the fundamental problems that people faced. And the biggest one that I took away from it was that basically \u003cem\u003epeople are playing computer inside their head\u003c/em\u003e.” Programmers were like chess players trying to play with a blindfold on—so much of their mental energy is spent just trying to picture where the pieces are that there’s hardly any left over to think about the game itself.\"},{\"__typename\":\"ArticlePullquote\",\"idAttr\":\"\",\"innerHtml\":\"Computers had doubled in power every 18 months for the last 40 years. Why hadn’t programming changed?\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"John Resig had been noticing the same thing among his students. Resig is a celebrated programmer of JavaScript—software he wrote powers over half of all websites—and a tech lead at the online-education site Khan Academy. In early 2012, he had been struggling with the site’s computer-science curriculum. Why was it so hard to learn to program? The essential problem seemed to be that code was so abstract. Writing software was not like making a bridge out of popsicle sticks, where you could see the sticks and touch the glue. To “make” a program, you typed words. When you wanted to change the behavior of the program, be it a game, or a website, or a simulation of physics, what you actually changed was text. So the students who did well—in fact the only ones who survived at all—were those who could step through that text one instruction at a time in their head, thinking the way a computer would, trying to keep track of every intermediate calculation. Resig, like Granger, started to wonder if it had to be that way. Computers had doubled in power every 18 months for the last 40 years. Why hadn’t programming changed?\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"The fact that the two of them were thinking about the same problem in the same terms, at the same time, was not a coincidence. They had both just seen the same remarkable talk, given to a group of software-engineering students in a Montreal hotel by a computer researcher named Bret Victor. The talk, which went viral when it was posted online in February 2012, seemed to be making two bold claims. The first was that the way we make software is fundamentally broken. The second was that Victor knew how to fix it.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":\"DROPCAP\",\"idAttr\":\"\",\"innerHtml\":\"B\u003cspan class=\\\"smallcaps\\\"\u003eret Victor does\u003c/span\u003e not like to write code. “It sounds weird,” he says. “When I want to make a thing, especially when I want to create something in software, there’s this initial layer of disgust that I have to push through, where I’m not manipulating the thing that I want to make, I’m writing a bunch of text into a text editor.”\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"“There’s a pretty strong conviction that that’s the wrong way of doing things.”\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"Victor has the mien of David Foster Wallace, with a lightning intelligence that lingers beneath a patina of aw-shucks shyness. He is 40 years old, with traces of gray and a thin, undeliberate beard. His voice is gentle, mournful almost, but he wants to share what’s in his head, and when he gets on a roll he’ll seem to skip syllables, as though outrunning his own vocal machinery.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"Though he runs a lab that studies the future of computing, he seems less interested in technology per se than in the minds of the people who use it. Like any good toolmaker, he has a way of looking at the world that is equal parts technical and humane. He graduated top of his class at the California Institute of Technology for electrical engineering, and then went on, after grad school at the University of California, Berkeley, to work at a company that develops music synthesizers. It was a problem perfectly matched to his dual personality: He could spend as much time thinking about the way a performer makes music with a keyboard—the way it becomes an extension of their hands—as he could thinking about the mathematics of digital signal processing.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"By the time he gave the talk that made his name, the one that Resig and Granger saw in early 2012, Victor had finally landed upon the principle that seemed to thread through all of his work. (He actually called the talk “Inventing on Principle.”) The principle was this: “Creators need an immediate connection to what they’re creating.” The problem with programming was that it violated the principle. That’s why software systems were so hard to think about, and so rife with bugs: The programmer, staring at a page of text, was abstracted from whatever it was they were actually making.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"“Our current conception of what a computer program is,” he said, is “derived straight from Fortran and ALGOL in the late ’50s. Those languages were designed for punch cards.” That code now takes the form of letters on a screen in a language like C or Java (derivatives of Fortran and ALGOL), instead of a stack of cards with holes in it, doesn’t make it any less dead, any less indirect.\"},{\"__typename\":\"ArticlePullquote\",\"idAttr\":\"\",\"innerHtml\":\"To Victor, the idea that people were trying to understand cancer by staring at a text editor was appalling.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"There is an analogy to word processing. It used to be that all you could see in a program for writing documents was the text itself, and to change the layout or font or margins, you had to write special “control codes,” or commands that would tell the computer that, for instance, “this part of the text should be in italics.” The trouble was that you couldn’t see the effect of those codes until you printed the document. It was hard to predict what you were going to get. You had to imagine how the codes were going to be interpreted by the computer—that is, you had to play computer in your head.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"Then WYSIWYG (pronounced “wizzywig”) came along. It stood for “What You See Is What You Get.” When you marked a passage as being in italics, the letters tilted right there on the screen. If you wanted to change the margin, you could drag a ruler at the top of the screen—and \u003cem\u003esee\u003c/em\u003e the effect of that change. The document thereby came to feel like something real, something you could poke and prod at. Just by looking you could tell if you’d done something wrong. Control of a sophisticated system—the document’s layout and formatting engine—was made accessible to anyone who could click around on a page.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"Victor’s point was that programming itself should be like that. For him, the idea that people were doing important work, like designing adaptive cruise-control systems or trying to understand cancer, by staring at a text editor, was appalling. And it was the proper job of programmers to ensure that someday they wouldn’t have to.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"There was precedent enough to suggest that this wasn’t a crazy idea. Photoshop, for instance, puts powerful image-processing algorithms in the hands of people who might not even know what an algorithm is. It’s a complicated piece of software, but complicated in the way a good synth is complicated, with knobs and buttons and sliders that the user learns to play like an instrument. Squarespace, a company that is perhaps best known for advertising aggressively on podcasts, makes a tool that lets users build websites by pointing and clicking, instead of by writing code in HTML and CSS. It is powerful enough to do work that once would have been done by a professional web designer.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"But those were just a handful of examples. The overwhelming reality was that when someone wanted to do something interesting with a computer, they had to write code. Victor, who is something of an idealist, saw this not so much as an opportunity but as a moral failing of programmers at large. His talk was a call to arms.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"At the heart of it was a series of demos that tried to show just how primitive the available tools were for various problems—circuit design, computer animation, debugging algorithms—and what better ones might look like. His demos were virtuosic. The one that captured everyone’s imagination was, ironically enough, the one that on its face was the most trivial. It showed a split screen with a game that looked like \u003cem\u003eMario\u003c/em\u003e on one side and the code that controlled it on the other. As Victor changed the code, things in the game world changed: He decreased one number, the strength of gravity, and the Mario character floated; he increased another, the player’s speed, and Mario raced across the screen.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"Suppose you wanted to design a level where Mario, jumping and bouncing off of a turtle, would \u003cem\u003ejust\u003c/em\u003e make it into a small passageway. Game programmers were used to solving this kind of problem in two stages: First, you stared at your code—the code controlling how high Mario jumped, how fast he ran, how bouncy the turtle’s back was—and made some changes to it in your text editor, using your imagination to predict what effect they’d have. Then, you’d replay the game to see what actually happened.\"},{\"__typename\":\"ArticleLegacyHtml\",\"tagName\":\"FIGURE\",\"idAttr\":\"\",\"className\":\"\",\"style\":\"\",\"innerHtml\":\"\u003cvideo autoplay=\\\"autoplay\\\" loop=\\\"loop\\\" muted=\\\"muted\\\" playsinline=\\\"playsinline\\\" poster=\\\"https://cdn.theatlantic.com/assets/media/files/videos/screen_shot_2017-09-20_at_10.09.49_am.jpg\\\" webkit-playsinline=\\\"webkit-playsinline\\\" width=\\\"100%\\\"\u003e\u003csource src=\\\"https://cdn.theatlantic.com/assets/media/files/videos/bret-victor-inventing-on-principle.mp4\\\"/\u003e Shadow Marios move on the left half of a screen as a mouse drags sliders on the right half.\u003c/video\u003e \u003cfigcaption class=\\\"credit\\\"\u003e\u003ca href=\\\"https://vimeo.com/36579366\\\"\u003eCUSEC / Vimeo\u003c/a\u003e\u003c/figcaption\u003e\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"Victor wanted something more immediate. “If you have a process in time,” he said, referring to Mario’s path through the level, “and you want to see changes immediately, you have to map time to space.” He hit a button that showed not just where Mario was right now, but where he would be at every moment in the future: a curve of shadow Marios stretching off into the far distance. What’s more, this projected path was reactive: When Victor changed the game’s parameters, now controlled by a quick drag of the mouse, the path’s shape changed. It was like having a god’s-eye view of the game. The whole problem had been reduced to playing with different parameters, as if adjusting levels on a stereo receiver, until you got Mario to thread the needle. With the right interface, it was almost as if you weren’t working with code at all; you were manipulating the game’s behavior directly.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"When the audience first saw this in action, they literally gasped. They knew they weren’t looking at a kid’s game, but rather the future of their industry. \u003cem\u003eMost\u003c/em\u003e software involved behavior that unfolded, in complex ways, over time, and Victor had shown that if you were imaginative enough, you could develop ways to see that behavior and change it, as if playing with it in your hands. One programmer who saw the talk wrote later: “Suddenly all of my tools feel obsolete.”\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":\"DROPCAP\",\"idAttr\":\"\",\"innerHtml\":\"W\u003cspan class=\\\"smallcaps\\\"\u003ehen John Resig\u003c/span\u003e saw the “Inventing on Principle” talk, he scrapped his plans for the Khan Academy programming curriculum. He wanted the site’s programming exercises to work just like Victor’s demos. On the left-hand side you’d have the code, and on the right, the running program: a picture or game or simulation. If you changed the code, it’d instantly change the picture. “In an environment that is truly responsive,” Resig wrote about the approach, “you can completely change the model of how a student learns ... [They] can now immediately see the result and intuit how underlying systems inherently work without ever following an explicit explanation.” Khan Academy has become perhaps the largest computer-programming class in the world, with a million students, on average, actively using the program each month.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"Chris Granger, who had worked at Microsoft on Visual Studio, was likewise inspired. Within days of seeing a video of Victor’s talk, in January of 2012, he built a prototype of a new programming environment. Its key capability was that it would give you instant feedback on your program’s behavior. You’d see what your system was doing right next to the code that controlled it. It was like taking off a blindfold. Granger called the project “Light Table.”\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"In April of 2012, he sought funding for Light Table on Kickstarter. In programming circles, it was a sensation. Within a month, the project raised more than $200,000. The ideas spread. The notion of \u003cem\u003eliveness\u003c/em\u003e, of being able to see data flowing through your program instantly, made its way into flagship programming tools offered by Google and Apple. The default language for making new iPhone and Mac apps, called Swift, was developed by Apple from the ground up to support an environment, called Playgrounds, that was directly inspired by Light Table.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"But seeing the impact that his talk ended up having, Bret Victor was disillusioned. “A lot of those things seemed like misinterpretations of what I was saying,” he said later. He knew something was wrong when people began to invite him to conferences to talk about programming tools. “Everyone thought I was interested in programming environments,” he said. Really he was interested in how people see and understand systems—as he puts it, in the “visual representation of dynamic behavior.” Although code had increasingly become the tool of choice for \u003cem\u003ecreating \u003c/em\u003edynamic behavior, it remained one of the worst tools for understanding it. The point of “Inventing on Principle” was to show that you could mitigate that problem by making the connection between a system’s behavior and its code immediate.\"},{\"__typename\":\"ArticlePullquote\",\"idAttr\":\"\",\"innerHtml\":\"“I’m not sure that programming has to exist at all.”\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"In a pair of later talks, “Stop Drawing Dead Fish” and “Drawing Dynamic Visualizations,” Victor went one further. He demoed two programs he’d built—the first for animators, the second for scientists trying to visualize their data—each of which took a process that used to involve writing lots of custom code and reduced it to playing around in a WYSIWYG interface. Victor suggested that the same trick could be pulled for nearly every problem where code was being written today. “I’m not sure that programming has to exist at all,” he told me. “Or at least software developers.” In his mind, a software developer’s proper role was to create tools that removed the need for software developers. Only then would people with the most urgent computational problems be able to grasp those problems directly, without the intermediate muck of code.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"Of course, to do that, you’d have to get programmers themselves on board. In a recent essay, Victor implored professional software developers to stop pouring their talent into tools for building apps like Snapchat and Uber. “The inconveniences of daily life are not the significant problems,” he wrote. Instead, they should focus on scientists and engineers—as he put it to me, “these people that are doing work that actually matters, and critically matters, and using really, really bad tools.” Exciting work of this sort, in particular a class of tools for “model-based design,” was already underway, he wrote, and had been for years, but most programmers knew nothing about it.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":\"DROPCAP\",\"idAttr\":\"\",\"innerHtml\":\"“I\u003cspan class=\\\"smallcaps\\\"\u003ef you really\u003c/span\u003e look hard at all the industrial goods that you’ve got out there, that you’re using, that companies are using, the only non-industrial stuff that you have inside this is the code.” Eric Bantégnie is the founder of Esterel Technologies (now owned by ANSYS), a French company that makes tools for building safety-critical software. Like Victor, Bantégnie doesn’t think engineers should develop large systems by typing millions of lines of code into an IDE. “Nobody would build a car by hand,” he says. “Code is still, in many places, handicraft. When you’re crafting manually 10,000 lines of code, that’s okay. But you have systems that have 30 million lines of code, like an Airbus, or 100 million lines of code, like your Tesla or high-end cars—that’s becoming very, very complicated.”\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"Bantégnie’s company is one of the pioneers in the industrial use of model-based design, in which you no longer write code directly. Instead, you create a kind of flowchart that describes the rules your program should follow (the “model”), and the computer generates code for you based on those rules. If you were making the control system for an elevator, for instance, one rule might be that when the door is open, and someone presses the button for the lobby, you should close the door and start moving the car. In a model-based design tool, you’d represent this rule with a small diagram, as though drawing the logic out on a whiteboard, made of boxes that represent different states—like “door open,” “moving,” and “door closed”—and lines that define how you can get from one state to the other. The diagrams make the system’s rules obvious: Just by looking, you can see that the only way to get the elevator moving is to close the door, or that the only way to get the door open is to stop.\"},{\"__typename\":\"ArticlePullquote\",\"idAttr\":\"\",\"innerHtml\":\"“The people know how to code. The problem is \u003cem\u003ewhat\u003c/em\u003e to code.”\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"It’s not quite Photoshop. The beauty of Photoshop, of course, is that the picture you’re manipulating on the screen \u003cem\u003eis\u003c/em\u003e the final product. In model-based design, by contrast, the picture on your screen is more like a blueprint. Still, making software this way is qualitatively different than traditional programming. In traditional programming, your task is to take complex rules and translate them into code; most of your energy is spent doing the translating, rather than thinking about the rules themselves. In the model-based approach, all you \u003cem\u003ehave\u003c/em\u003e is the rules. So that’s what you spend your time thinking about. It’s a way of focusing less on the machine and more on the problem you’re trying to get it to solve.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"“Typically the main problem with software coding—and I’m a coder myself,” Bantégnie says, “is not the skills of the coders. The people know how to code. The problem is \u003cem\u003ewhat\u003c/em\u003e to code. Because most of the requirements are kind of natural language, ambiguous, and a requirement is never extremely precise, it’s often understood differently by the guy who’s supposed to code.”\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"On this view, software becomes unruly because the media for describing what software \u003cem\u003eshould\u003c/em\u003e do—conversations, prose descriptions, drawings on a sheet of paper—are too different from the media describing what software \u003cem\u003edoes\u003c/em\u003e do, namely, code itself. Too much is lost going from one to the other. The idea behind model-based design is to close the gap. The very same model is used both by system designers to express what they want and by the computer to automatically generate code.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"Of course, for this approach to succeed, much of the work has to be done well before the project even begins. Someone first has to build a tool for developing models that are natural for people—that feel just like the notes and drawings they’d make on their own—while still being unambiguous enough for a computer to understand. They have to make a program that turns these models into real code. And finally they have to prove that the generated code will always do what it’s supposed to. “We have benefited from fortunately 20 years of initial background work,” Bantégnie says.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"Esterel Technologies, which was acquired by ANSYS in 2012, grew out of research begun in the 1980s by the French nuclear and aerospace industries, who worried that as safety-critical code ballooned in complexity, it was getting harder and harder to keep it free of bugs. “I started in 1988,” says Emmanuel Ledinot, the Head of Scientific Studies for Dassault Aviation, a French manufacturer of fighter jets and business aircraft. “At the time, I was working on military avionics systems. And the people in charge of integrating the systems, and debugging them, had noticed that the number of bugs was increasing.” The 80s had seen a surge in the number of onboard computers on planes. Instead of a single flight computer, there were now dozens, each responsible for highly specialized tasks related to control, navigation, and communications. Coordinating these systems to fly the plane as data poured in from sensors and as pilots entered commands required a symphony of perfectly timed reactions. “The handling of these hundreds of and even thousands of possible events in the right order, at the right time,” Ledinot says, “was diagnosed as the main cause of the bug inflation.”\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"Ledinot decided that writing such convoluted code by hand was no longer sustainable. It was too hard to understand what it was doing, and almost impossible to verify that it would work correctly. He went looking for something new. “You must understand that to change tools is extremely expensive in a process like this,” he said in a talk. “You don’t take this type of decision unless your back is against the wall.”\"},{\"__typename\":\"ArticlePullquote\",\"idAttr\":\"\",\"innerHtml\":\"Most programmers \u003cem\u003elike\u003c/em\u003e code. At least they understand it.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"He began collaborating with Gerard Berry, a computer scientist at INRIA, the French computing-research center, on a tool called Esterel—a portmanteau of the French for “real-time.” The idea behind Esterel was that while traditional programming languages might be good for describing simple procedures that happened in a predetermined order—like a recipe—if you tried to use them in systems where lots of events could happen at nearly any time, in nearly any order—like in the cockpit of a plane—you inevitably got a mess. And a mess in control software was dangerous. In a paper, Berry went as far as to predict that “low-level programming techniques will not remain acceptable for large safety-critical programs, since they make behavior understanding and analysis almost impracticable.”\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"Esterel was designed to make the computer handle this complexity for you. That was the promise of the model-based approach: Instead of writing normal programming code, you created a model of the system’s behavior—in this case, a model focused on how individual events should be handled, how to prioritize events, which events depended on which others, and so on. The model becomes the detailed blueprint that the computer would use to do the actual programming.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"Ledinot and Berry worked for nearly 10 years to get Esterel to the point where it could be used in production. “It was in 2002 that we had the first operational software-modeling environment with automatic code generation,” Ledinot told me, “and the first embedded module in Rafale, the combat aircraft.” Today, the ANSYS SCADE product family (for “safety-critical application development environment”) is used to generate code by companies in the aerospace and defense industries, in nuclear power plants, transit systems, heavy industry, and medical devices. “My initial dream was to have SCADE-generated code in every plane in the world,” Bantégnie, the founder of Esterel Technologies, says, “and we’re not very far off from that objective.” Nearly all safety-critical code on the Airbus A380, including the system controlling the plane’s flight surfaces, was generated with ANSYS SCADE products.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"Part of the draw for customers, especially in aviation, is that while it is possible to build highly reliable software by hand, it can be a Herculean effort. Ravi Shivappa, the VP of group software engineering at Meggitt PLC, an ANSYS customer which builds components for airplanes, like pneumatic fire detectors for engines, explains that traditional projects begin with a massive requirements document in English, which specifies everything the software should do. (A requirement might be something like, “When the pressure in this section rises above a threshold, open the safety valve, unless the manual-override switch is turned on.”) The problem with describing the requirements this way is that when you implement them in code, you have to painstakingly check that each one is satisfied. And when the customer changes the requirements, the code has to be changed, too, and tested extensively to make sure that nothing else was broken in the process.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"The cost is compounded by exacting regulatory standards. The FAA is fanatical about software safety. The agency mandates that every requirement for a piece of safety-critical software be traceable to the lines of code that implement it, and vice versa. So every time a line of code changes, it must be retraced to the corresponding requirement in the design document, and you must be able to demonstrate that the code actually satisfies the requirement. The idea is that if something goes wrong, you’re able to figure out why; the practice brings order and accountability to large codebases. But, Shivappa says, “it’s a very labor-intensive process.” He estimates that before they used model-based design, on a two-year-long project only two to three months was spent writing code—the rest was spent working on the documentation.\"},{\"__typename\":\"ArticlePullquote\",\"idAttr\":\"\",\"innerHtml\":\"We already know how to make complex software reliable, but in so many places, we’re choosing not to.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"As Bantégnie explains, the beauty of having a computer turn your requirements into code, rather than a human, is that you can be sure—in fact you can mathematically prove—that the generated code actually satisfies those requirements. Much of the benefit of the model-based approach comes from being able to add requirements on the fly while still ensuring that existing ones are met; with every change, the computer can verify that your program still works. You’re free to tweak your blueprint without fear of introducing new bugs. Your code is, in FAA parlance, “correct by construction.”\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"Still, most software, even in the safety-obsessed world of aviation, is made the old-fashioned way, with engineers writing their requirements in prose and programmers coding them up in a programming language like C. As Bret Victor made clear in his essay, model-based design is relatively unusual. “A lot of people in the FAA think code generation is magic, and hence call for greater scrutiny,” Shivappa told me.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"Most programmers feel the same way. They \u003cem\u003elike\u003c/em\u003e code. At least they understand it. Tools that write your code for you and verify its correctness using the mathematics of “finite-state machines” and “recurrent systems” sound esoteric and hard to use, if not just too good to be true.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"It is a pattern that has played itself out before. Whenever programming has taken a step away from the writing of literal ones and zeros, the loudest objections have come from programmers. Margaret Hamilton, a celebrated software engineer on the Apollo missions—in fact the coiner of the phrase “software engineering”—told me that during her first year at the Draper lab at MIT, in 1964, she remembers a meeting where one faction was fighting the other about transitioning away from “some very low machine language,” as close to ones and zeros as you could get, to “assembly language.” “The people at the lowest level were fighting to keep it. And the arguments were so similar: ‘Well how do we know assembly language is going to do it right?’”\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"“Guys on one side, their faces got red, and they started screaming,” she said. She said she was “amazed how emotional they got.”\"},{\"__typename\":\"ArticlePullquote\",\"idAttr\":\"\",\"innerHtml\":\"You could do all the testing you wanted and you’d never find all the bugs.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"Emmanuel Ledinot, of Dassault Aviation, pointed out that when assembly language was itself phased out in favor of the programming languages still popular today, like C, it was the assembly programmers who were skeptical this time. No wonder, he said, that “people are not so easily transitioning to model-based software development: They perceive it as another opportunity to lose control, even more than they have already.”\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"The bias against model-based design, sometimes known as model-driven engineering, or MDE, is in fact so ingrained that according to a recent paper, “Some even argue that there is a stronger need to investigate people’s perception of MDE than to research new MDE technologies.”\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"Which sounds almost like a joke, but for proponents of the model-based approach, it’s an important point: We already know how to make complex software reliable, but in so many places, we’re choosing not to. Why?\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":\"DROPCAP\",\"idAttr\":\"\",\"innerHtml\":\"I\u003cspan class=\\\"smallcaps\\\"\u003en 2011, Chris\u003c/span\u003e Newcombe had been working at Amazon for almost seven years, and had risen to be a principal engineer. He had worked on some of the company’s most critical systems, including the retail-product catalog and the infrastructure that managed every Kindle device in the world. He was a leader on the highly prized Amazon Web Services team, which maintains cloud servers for some of the web’s biggest properties, like Netflix, Pinterest, and Reddit. Before Amazon, he’d helped build the backbone of Steam, the world’s largest online-gaming service. He is one of those engineers whose work quietly keeps the internet running. The products he’d worked on were considered massive successes. But all he could think about was that buried deep in the designs of those systems were disasters waiting to happen.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"“Human intuition is poor at estimating the true probability of supposedly ‘extremely rare’ combinations of events in systems operating at a scale of millions of requests per second,” he wrote in a paper. “That human fallibility means that some of the more subtle, dangerous bugs turn out to be errors in design; the code faithfully implements the intended design, but the design fails to correctly handle a particular ‘rare’ scenario.”\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"Newcombe was convinced that the algorithms behind truly critical systems—systems storing a significant portion of the web’s data, for instance—ought to be not just good, but perfect. A single subtle bug could be catastrophic. But he knew how hard bugs were to find, especially as an algorithm grew more complex. You could do all the testing you wanted and you’d never find them all.\"},{\"__typename\":\"ArticlePullquote\",\"idAttr\":\"\",\"innerHtml\":\"“Few programmers write even a rough sketch of what their programs will do before they start coding.”\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"This is why he was so intrigued when, in the appendix of a paper he’d been reading, he came across a strange mixture of math and code—or what looked like code—that described an algorithm in something called “TLA+.” The surprising part was that this description was said to be mathematically precise: An algorithm written in TLA+ could in principle be \u003cem\u003eproven\u003c/em\u003e correct. In practice, it allowed you to create a realistic model of your problem and test it not just thoroughly, but \u003cem\u003eexhaustively\u003c/em\u003e. This was exactly what he’d been looking for: a language for writing perfect algorithms.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"TLA+, which stands for “Temporal Logic of Actions,” is similar in spirit to model-based design: It’s a language for writing down the requirements—TLA+ calls them “specifications”—of computer programs. These specifications can then be completely verified by a computer. That is, before you write any code, you write a concise outline of your program’s logic, along with the constraints you need it to satisfy (say, if you were programming an ATM, a constraint might be that you can never withdraw the same money twice from your checking account). TLA+ then exhaustively checks that your logic does, in fact, satisfy those constraints. If not, it will show you exactly how they could be violated.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"The language was invented by Leslie Lamport, a Turing Award–winning computer scientist. With a big white beard and scruffy white hair, and kind eyes behind large glasses, Lamport looks like he might be one of the friendlier professors at the American Hogwarts. Now at Microsoft Research, he is known as one of the pioneers of the theory of “distributed systems,” which describes any computer system made of multiple parts that communicate with each other. Lamport’s work laid the foundation for many of the systems that power the modern web.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"For Lamport, a major reason today’s software is so full of bugs is that programmers jump straight into writing code. “Architects draw detailed plans before a brick is laid or a nail is hammered,” he wrote in an article. “But few programmers write even a rough sketch of what their programs will do before they start coding.” Programmers are drawn to the nitty-gritty of coding because code is what makes programs go; spending time on anything else can seem like a distraction. And there is a patient joy, a meditative kind of satisfaction, to be had from puzzling out the micro-mechanics of code. But code, Lamport argues, was never meant to be a medium for thought. “It really does constrain your ability to think when you’re thinking in terms of a programming language,” he says. Code makes you miss the forest for the trees: It draws your attention to the working of individual pieces, rather than to the bigger picture of how your program fits together, or what it’s supposed to do—and whether it actually does what you think. This is why Lamport created TLA+. As with model-based design, TLA+ draws your focus to the high-level structure of a system, its essential logic, rather than to the code that implements it.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"Newcombe and his colleagues at Amazon would go on to use TLA+ to find subtle, critical bugs in major systems, including bugs in the core algorithms behind S3, regarded as perhaps the most reliable storage engine in the world. It is now used widely at the company. In the tiny universe of people who had ever used TLA+, their success was not so unusual. An intern at Microsoft used TLA+ to catch a bug that could have caused every Xbox in the world to crash after four hours of use. Engineers at the European Space Agency used it to rewrite, with 10 times less code, the operating system of a probe that was the first to ever land softly on a comet. Intel uses it regularly to verify its chips.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"But TLA+ occupies just a small, far corner of the mainstream, if it can be said to take up any space there at all. Even to a seasoned engineer like Newcombe, the language read at first as bizarre and esoteric—a zoo of symbols. For Lamport, this is a failure of education. Though programming was born in mathematics, it has since largely been divorced from it. Most programmers aren’t very fluent in the kind of math—logic and set theory, mostly—that you need to work with TLA+. “Very few programmers—and including very few teachers of programming—understand the very basic concepts and how they’re applied in practice. And they seem to think that all they need is code,” Lamport says. “The idea that there’s some higher level than the code in which you need to be able to think precisely, and that mathematics actually allows you to think precisely about it, is just completely foreign. Because they never learned it.”\"},{\"__typename\":\"ArticlePullquote\",\"idAttr\":\"\",\"innerHtml\":\"“I hope people won’t be allowed to write programs if they don’t understand these simple things.”\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"Lamport sees this failure to think mathematically about what they’re doing as the problem of modern software development in a nutshell: The stakes keep rising, but programmers aren’t stepping up—they haven’t developed the chops required to handle increasingly complex problems. “In the 15th century,” he said, “people used to build cathedrals without knowing calculus, and nowadays I don’t think you’d \u003cem\u003eallow\u003c/em\u003e anyone to build a cathedral without knowing calculus. And I would hope that after some suitably long period of time, people won’t be allowed to write programs if they don’t understand these simple things.”\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"Newcombe isn’t so sure that it’s the programmer who is to blame. “I’ve heard from Leslie that he thinks programmers are afraid of math. I’ve found that programmers aren’t aware—or don’t believe—that math can help them handle complexity. Complexity is the biggest challenge for programmers.” The real problem in getting people to use TLA+, he said, was convincing them it wouldn’t be a waste of their time. Programmers, as a species, are relentlessly pragmatic. Tools like TLA+ reek of the ivory tower. When programmers encounter “formal methods” (so called because they involve mathematical, “formally” precise descriptions of programs), their deep-seated instinct is to recoil.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"Most programmers who took computer science in college have briefly encountered formal methods. Usually they’re demonstrated on something trivial, like a program that counts up from zero; the student’s job is to mathematically prove that the program does, in fact, count up from zero.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"“I needed to change people’s perceptions on what formal methods were,” Newcombe told me. Even Lamport himself didn’t seem to fully grasp this point: Formal methods had an image problem. And the way to fix it wasn’t to implore programmers to change—it was to change yourself. Newcombe realized that to bring tools like TLA+ to the programming mainstream, you had to start speaking their language.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"For one thing, he said that when he was introducing colleagues at Amazon to TLA+ he would avoid telling them what it stood for, because he was afraid the name made it seem unnecessarily forbidding: “Temporal Logic of Actions” has exactly the kind of highfalutin ring to it that plays well in academia, but puts off most practicing programmers. He tried also not to use the terms “formal,” “verification,” or “proof,” which reminded programmers of tedious classroom exercises. Instead, he presented TLA+ as a new kind of “pseudocode,” a stepping-stone to real code that allowed you to exhaustively test your algorithms—and that got you thinking precisely early on in the design process. “Engineers think in terms of debugging rather than ‘verification,’” he wrote, so he titled his internal talk on the subject to fellow Amazon engineers “Debugging Designs.” Rather than bemoan the fact that programmers see the world in code, Newcombe embraced it. He knew he’d lose them otherwise. “I’ve had a bunch of people say, ‘Now I get it,’” Newcombe says.\"},{\"__typename\":\"ArticlePullquote\",\"idAttr\":\"\",\"innerHtml\":\"This code has created a level of complexity that is entirely new. And it has made possible a new kind of failure.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"He has since left Amazon for Oracle, where he’s been able to convince his new colleagues to give TLA+ a try. For him, using these tools is now a matter of responsibility. “We need to get better at this,” he said.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"“I’m self-taught, been coding since I was nine, so my instincts were to start coding. That was my only—that was my way of thinking: You’d sketch something, try something, you’d organically evolve it.” In his view, this is what many programmers today still do. “They google, and they look on Stack Overflow” (a popular website where programmers answer each other’s technical questions) “and they get snippets of code to solve their tactical concern in this little function, and they glue it together, and iterate.”\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"“And that’s completely fine until you run smack into a real problem.”\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":\"DROPCAP\",\"idAttr\":\"\",\"innerHtml\":\"I\u003cspan class=\\\"smallcaps\\\"\u003en the summer\u003c/span\u003e of 2015, a pair of American security researchers, Charlie Miller and Chris Valasek, convinced that car manufacturers weren’t taking software flaws seriously enough, demonstrated that a 2014 Jeep Cherokee could be remotely controlled by hackers. They took advantage of the fact that the car’s entertainment system, which has a cellular connection (so that, for instance, you can start your car with your iPhone), was connected to more central systems, like the one that controls the windshield wipers, steering, acceleration, and brakes (so that, for instance, you can see guidelines on the rearview screen that respond as you turn the wheel). As proof of their attack, which they developed on nights and weekends, they hacked into Miller’s car while a journalist was driving it on the highway, and made it go haywire; the journalist, who knew what was coming, panicked when they cut the engines, forcing him to a slow crawl on a stretch of road with no shoulder to escape to.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"Although they didn’t actually create one, they showed that it was possible to write a clever piece of software, a “vehicle worm,” that would use the onboard computer of a hacked Jeep Cherokee to scan for and hack others; had they wanted to, they could have had simultaneous access to a nationwide fleet of vulnerable cars and SUVs. (There were at least five Fiat Chrysler models affected, including the Jeep Cherokee.) One day they could have told them all to, say, suddenly veer left or cut the engines at high speed.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"“We need to think about software differently,” Valasek told me. Car companies have long assembled their final product from parts made by hundreds of different suppliers. But where those parts were once purely mechanical, they now, as often as not, come with millions of lines of code. And while some of this code—for adaptive cruise control, for auto braking and lane assist—has indeed made cars safer (“The safety features on my Jeep have already saved me countless times,” says Miller), it has also created a level of complexity that is entirely new. And it has made possible a new kind of failure.\"},{\"__typename\":\"ArticlePullquote\",\"idAttr\":\"\",\"innerHtml\":\"In the world of the self-driving car, software can’t be an afterthought.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"“There are lots of bugs in cars,” Gerard Berry, the French researcher behind Esterel, said in a talk. “It’s not like avionics—in avionics it’s taken very seriously. And it’s admitted that software is different from mechanics.” The automotive industry is perhaps among those that haven’t yet realized they are actually in the software business.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"“We don’t in the automaker industry have a regulator for software safety that knows what it’s doing,” says Michael Barr, the software expert who testified in the Toyota case. NHTSA, he says, “has only limited software expertise. They’ve come at this from a mechanical history.” The same regulatory pressures that have made model-based design and code generation attractive to the aviation industry have been slower to come to car manufacturing. Emmanuel Ledinot, of Dassault Aviation, speculates that there might be economic reasons for the difference, too. Automakers simply can’t afford to increase the price of a component by even a few cents, since it is multiplied so many millionfold; the computers embedded in cars therefore have to be slimmed down to the bare minimum, with little room to run code that hasn’t been hand-tuned to be as lean as possible. “Introducing model-based software development was, I think, for the last decade, too costly for them.”\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"One suspects the incentives are changing. “I think the autonomous car might push them,” Ledinot told me—“ISO 26262 and the autonomous car might slowly push them to adopt this kind of approach on critical parts.” (ISO 26262 is a safety standard for cars published in 2011.) Barr said much the same thing: In the world of the self-driving car, software can’t be an afterthought. It can’t be built like today’s airline-reservation systems or 911 systems or stock-trading systems. Code will be put in charge of hundreds of millions of lives on the road and it has to work. That is no small task.\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"“Computing is fundamentally invisible,” Gerard Berry said in his talk. “When your tires are flat, you look at your tires, they are flat. When your software is broken, you look at your software, you see nothing.”\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"“So that’s a big problem.”\"},{\"__typename\":\"ArticleLegacyHtml\",\"tagName\":\"HR\",\"idAttr\":\"\",\"className\":\"\",\"style\":\"\",\"innerHtml\":\"\"},{\"__typename\":\"ArticleParagraphContent\",\"subtype\":null,\"idAttr\":\"\",\"innerHtml\":\"\u003csmall\u003e\u003ca data-event-element=\\\"inline link\\\" id=\\\"Correction\\\" name=\\\"Correction\\\"\u003e\u003c/a\u003e\u003ca data-event-element=\\\"inline link\\\" href=\\\"#Key%20Tasks\\\"\u003e*\u003c/a\u003e \u003cem\u003eThis article originally stated that there were 10 million ways for the Toyota Camry to cause unintended acceleration. We regret the error.\u003c/em\u003e\u003c/small\u003e\"}],\"editorialProject\":null,\"primaryCategory\":{\"__typename\":\"Channel\",\"displayName\":\"Technology\",\"url\":\"https://www.theatlantic.com/technology/\",\"slug\":\"technology\"},\"primaryChannel\":{\"slug\":\"technology\",\"__typename\":\"Channel\",\"displayName\":\"Technology\"},\"reviews\":[],\"embeds\":[{\"type\":\"iframe\",\"src\":\"https://w.soundcloud.com/player/?url=https%3A//api.soundcloud.com/tracks/346597527\u0026color=%23ff5500\u0026color=%23ff5500\u0026inverse=true\u0026auto_play=false\u0026show_user=true\",\"__typename\":\"Embed\"}],\"preview\":null,\"tags\":[],\"layout\":\"feature\",\"secondaryByline\":\"\",\"dek\":\"A small group of programmers wants to change how we code—before catastrophe strikes.\",\"url\":\"https://www.theatlantic.com/technology/archive/2017/09/saving-the-world-from-code/540393/\",\"shareText\":\"The coming software apocalypse, by @jsomers\",\"shareTitle\":\"The Coming Software Apocalypse\",\"title\":\"The Coming Software Apocalypse\",\"datePublished\":\"2017-09-26T15:10:42Z\",\"audio\":null,\"hasAudioRights\":null,\"editorsNote\":null,\"leadArt\":{\"__typename\":\"LeadArtImageLarge\",\"image\":{\"url\":\"https://cdn.theatlantic.com/thumbor/iTzwN-qrMZdubIcExn-2pLs7t80=/108x230:1897x1236/1440x810/media/img/2017/09/21/TheAtlantic_CodeFinal3/original.png\",\"width\":1440,\"height\":810,\"srcSet\":\"https://cdn.theatlantic.com/thumbor/6Ln6NcHA-BoP2VR_nwDteVywXn8=/108x230:1897x1236/640x360/media/img/2017/09/21/TheAtlantic_CodeFinal3/original.png 640w, https://cdn.theatlantic.com/thumbor/DhlrPoqTvIdglIRxFSSKNUHqg5E=/108x230:1897x1236/750x422/media/img/2017/09/21/TheAtlantic_CodeFinal3/original.png 750w, https://cdn.theatlantic.com/thumbor/5My8Q2BelrqNVX9AqSZlQrd14Cg=/108x230:1897x1236/850x478/media/img/2017/09/21/TheAtlantic_CodeFinal3/original.png 850w, https://cdn.theatlantic.com/thumbor/y82l57Br304M0irZ_SyHdfyQ9vE=/108x230:1897x1236/1536x864/media/img/2017/09/21/TheAtlantic_CodeFinal3/original.png 1536w\",\"reducedMotionSrcSet\":null,\"altText\":\"Cartoonish figures interact with the world through code.\",\"captionText\":\"\",\"attributionText\":\"Lynn Scurfield\",\"attributionUrl\":\"\",\"__typename\":\"BasicImage\"}},\"narratedAudioImage\":{\"url\":\"https://cdn.theatlantic.com/thumbor/sol_7eHNCMutcPc3URXTNMCZZUo=/333x0:1666x1333/80x80/media/img/mt/2017/09/TheAtlantic_CodeFinal3/original.png\",\"srcSet\":\"https://cdn.theatlantic.com/thumbor/sol_7eHNCMutcPc3URXTNMCZZUo=/333x0:1666x1333/80x80/media/img/mt/2017/09/TheAtlantic_CodeFinal3/original.png 80w, https://cdn.theatlantic.com/thumbor/3djxta4KC-6SU29WTxFoQ9cz0Jw=/333x0:1666x1333/96x96/media/img/mt/2017/09/TheAtlantic_CodeFinal3/original.png 96w, https://cdn.theatlantic.com/thumbor/_WBq04DLPFHOBmj_LE3cBVZsFuM=/333x0:1666x1333/128x128/media/img/mt/2017/09/TheAtlantic_CodeFinal3/original.png 128w, https://cdn.theatlantic.com/thumbor/OPP24d1Pa7EUBFmVozyR_7RpdX4=/333x0:1666x1333/160x160/media/img/mt/2017/09/TheAtlantic_CodeFinal3/original.png 160w, https://cdn.theatlantic.com/thumbor/xAcuikzxdh9hhIyh3N3tm3fFVco=/333x0:1666x1333/192x192/media/img/mt/2017/09/TheAtlantic_CodeFinal3/original.png 192w, https://cdn.theatlantic.com/thumbor/3UXaO09g762yshEDcFtH-Vc9VCY=/333x0:1666x1333/256x256/media/img/mt/2017/09/TheAtlantic_CodeFinal3/original.png 256w, https://cdn.theatlantic.com/thumbor/LC65zjIg9LWsaVfEWpwr7ptw0qw=/333x0:1666x1333/384x384/media/img/mt/2017/09/TheAtlantic_CodeFinal3/original.png 384w, https://cdn.theatlantic.com/thumbor/eNVJIcXwaS1mcDKo5xg-EU4uDA4=/333x0:1666x1333/512x512/media/img/mt/2017/09/TheAtlantic_CodeFinal3/original.png 512w\",\"reducedMotionSrcSet\":null,\"width\":80,\"height\":80,\"altText\":\"Cartoonish figures interact with the world through code.\",\"__typename\":\"BasicImage\"},\"comments\":{\"totalComments\":0,\"isClosed\":true,\"storyPrompt\":null,\"featuredComments\":[],\"__typename\":\"CoralStory\"},\"seoTitle\":\"The Coming Software Apocalypse\",\"hasMeter\":true,\"channels\":[{\"slug\":\"technology\",\"__typename\":\"Channel\"}],\"shareDek\":\"A small group of programmers wants to change how we code—before catastrophe strikes.\",\"fbiaUrl\":null,\"canonicalUrl\":\"https://www.theatlantic.com/technology/archive/2017/09/saving-the-world-from-code/540393/\",\"dateModified\":\"2017-11-16T16:26:59Z\",\"syndication\":\"ALL\",\"shareImage2x1\":{\"url\":\"https://cdn.theatlantic.com/thumbor/ud_p3Hp5As5Wjz7gZ9GAcZXdObo=/0x187:1997x1227/1200x625/media/img/mt/2017/09/TheAtlantic_CodeFinal3/original.png\",\"height\":625,\"width\":1200,\"__typename\":\"BasicImage\"},\"shareImageGift2x1\":{\"url\":\"https://cdn.theatlantic.com/thumbor/QXDITSBhyMIAQjehEvLDzyJi0DQ=/0x187:1997x1227/1200x625/filters:watermark(https://cdn.theatlantic.com/media/files/badge_2x.png,-20,20,0,33)/media/img/mt/2017/09/TheAtlantic_CodeFinal3/original.png\",\"height\":625,\"width\":1200,\"__typename\":\"BasicImage\"},\"shareImageGiftSmall\":{\"url\":\"https://cdn.theatlantic.com/thumbor/ba1b-xunFS_VAoDWUbNxbr3K9DU=/4x185:1993x1229/960x504/filters:watermark(https://cdn.theatlantic.com/media/files/badge_2x.png,-20,20,0,33)/media/img/mt/2017/09/TheAtlantic_CodeFinal3/original.png\",\"height\":504,\"width\":960,\"__typename\":\"BasicImage\"},\"shareImageComment2x1\":{\"url\":\"https://cdn.theatlantic.com/thumbor/hhsu3FVK82-rGQRr3Da2hwT2hD8=/0x187:1997x1227/1200x625/filters:watermark(https://cdn.theatlantic.com/media/files/share_badge_discussion.png,-20,20,0,33)/media/img/mt/2017/09/TheAtlantic_CodeFinal3/original.png\",\"height\":625,\"width\":1200,\"__typename\":\"BasicImage\"},\"shareImageCommentSmall\":{\"url\":\"https://cdn.theatlantic.com/thumbor/A1_0htUZhIc-xD9mn8DnvLuqcSk=/4x185:1993x1229/960x504/filters:watermark(https://cdn.theatlantic.com/media/files/share_badge_discussion.png,-20,20,0,33)/media/img/mt/2017/09/TheAtlantic_CodeFinal3/original.png\",\"height\":504,\"width\":960,\"__typename\":\"BasicImage\"},\"shareImageSmall\":{\"url\":\"https://cdn.theatlantic.com/thumbor/uqmKimBDiOIBQBSOpK_N8Tl9vjU=/4x185:1993x1229/960x504/media/img/mt/2017/09/TheAtlantic_CodeFinal3/original.png\",\"height\":504,\"width\":960,\"__typename\":\"BasicImage\"},\"shareImage1x1\":{\"width\":1080,\"height\":1080,\"url\":\"https://cdn.theatlantic.com/thumbor/rcwVU6YYyo0y93UdHzou7MHO--Q=/333x0:1666x1333/1080x1080/media/img/mt/2017/09/TheAtlantic_CodeFinal3/original.png\",\"__typename\":\"BasicImage\"},\"shareImage16x9\":{\"width\":1600,\"height\":900,\"url\":\"https://cdn.theatlantic.com/thumbor/T7QNU05oi2SNFmre1SzuR4P1D1s=/0x102:2000x1227/1600x900/media/img/mt/2017/09/TheAtlantic_CodeFinal3/original.png\",\"__typename\":\"BasicImage\"},\"shareImage4x3\":{\"width\":1200,\"height\":900,\"url\":\"https://cdn.theatlantic.com/thumbor/1lRzKc7cjwTehI6auY2wbioJZRE=/111x0:1888x1333/1200x900/media/img/mt/2017/09/TheAtlantic_CodeFinal3/original.png\",\"__typename\":\"BasicImage\"},\"shareImageDefault\":{\"width\":960,\"height\":540,\"url\":\"https://cdn.theatlantic.com/thumbor/ghDkv236UfxsA_WV_ShjsXIq-Mo=/0x102:2000x1227/960x540/media/img/mt/2017/09/TheAtlantic_CodeFinal3/original.png\",\"__typename\":\"BasicImage\"},\"shareImageSquareDefault\":{\"width\":540,\"height\":540,\"url\":\"https://cdn.theatlantic.com/thumbor/-g21VhY08h6EVTY4xldi3KRSqzQ=/333x0:1666x1333/540x540/media/img/mt/2017/09/TheAtlantic_CodeFinal3/original.png\",\"__typename\":\"BasicImage\"},\"shareImageLeadArt\":{\"__typename\":\"LeadArtImageLarge\"},\"slug\":\"saving-the-world-from-code\"}}"}},"urqlClient":null},"isSocialBot":false},"page":"/[channel]/archive/[year]/[month]/[slug]/[id]","query":{"channel":"technology","year":"2017","month":"09","slug":"saving-the-world-from-code","id":"540393"},"buildId":"69tsob48ZMDbtI0c_5sg3","assetPrefix":"https://cdn.theatlantic.com","runtimeConfig":{"GTM_CONTAINER_ID":"GTM-NTQTB9V","GTM_CONTAINER_ID_NONCONSENTED":"GTM-5839GV7","GTM_CONTAINER_ID_WEBVIEW":"GTM-TRJJ8RJ4","GTM_GATEWAY_PATH_CONSENTED":"/gtmc","GTM_GATEWAY_PATH_NONCONSENTED":"/gtmn","GTM_GATEWAY_PATH_WEBVIEW":"/gtmm","CORAL_URL":"https://coral.theatlantic.com","GRAPHQL_API_URL":"https://graphql.theatlantic.com","GRAPHQL_API_KEY":"JakhyMEXwa9odtB8gBxFI63ITyKqDGkn7ciGVIJf","ADS_LIB_URL":"https://www.theatlantic.com/packages/hummingbirdjs/hummingbird.min.js","ACCOUNTS_FRONTEND_URL":"https://accounts.theatlantic.com","ENABLE_FEATURE_ARTICLE_RENDER":"false","RECAPTCHA_SITE_KEY":"6Lc9Z7AUAAAAAEYS1dgAG2_6tT3KLqZQ1z4kbDRc","BETA_ENV":false},"isFallback":false,"isExperimentalCompile":false,"dynamicIds":[48476,34958],"gip":true,"appGip":true,"scriptLoader":[]}</script><script nomodule="" src="https://cdn.theatlantic.com/_next/static/chunks/polyfills-42372ed130431b0a.js"></script><script async="" src="https://cdn.theatlantic.com/_next/static/chunks/8476.695f762283eb3a7a.js"></script><script src="https://cdn.theatlantic.com/_next/static/chunks/webpack-459d7a8ce0f9e787.js" async=""></script><script src="https://cdn.theatlantic.com/_next/static/chunks/framework-b9fd9bcc3ecde907.js" async=""></script><script src="https://cdn.theatlantic.com/_next/static/chunks/main-1e3f07e508c9deb1.js" async=""></script><script src="https://cdn.theatlantic.com/_next/static/chunks/pages/_app-eb71c0d56c56049a.js" async=""></script><script src="https://cdn.theatlantic.com/_next/static/chunks/1851-e6d0404216255e04.js" async=""></script><script src="https://cdn.theatlantic.com/_next/static/chunks/6636-bc98ad1f3cd91596.js" async=""></script><script src="https://cdn.theatlantic.com/_next/static/chunks/3797-f8042da41ece45a6.js" async=""></script><script src="https://cdn.theatlantic.com/_next/static/chunks/2296-0ecf836df9c60165.js" async=""></script><script src="https://cdn.theatlantic.com/_next/static/chunks/5683-10fee38148845c4a.js" async=""></script><script src="https://cdn.theatlantic.com/_next/static/chunks/1790-7d35389f9e543b1d.js" async=""></script><script src="https://cdn.theatlantic.com/_next/static/chunks/4299-a4b3ac3873e55247.js" async=""></script><script src="https://cdn.theatlantic.com/_next/static/chunks/6976-da5685274cf13d59.js" async=""></script><script src="https://cdn.theatlantic.com/_next/static/chunks/1747-9d561606d4c5bdea.js" async=""></script><script src="https://cdn.theatlantic.com/_next/static/chunks/5671-409d5aba090bd11d.js" async=""></script><script src="https://cdn.theatlantic.com/_next/static/chunks/5539-292b7ebdeac3fbb8.js" async=""></script><script src="https://cdn.theatlantic.com/_next/static/chunks/808-25295386c27f4971.js" async=""></script><script src="https://cdn.theatlantic.com/_next/static/chunks/4499-8ce342ce305a927c.js" async=""></script><script src="https://cdn.theatlantic.com/_next/static/chunks/6503-09da97c356ee7944.js" async=""></script><script src="https://cdn.theatlantic.com/_next/static/chunks/9938-950cf6b0a960f8a4.js" async=""></script><script src="https://cdn.theatlantic.com/_next/static/chunks/7010-0e727db2863a9d5c.js" async=""></script><script src="https://cdn.theatlantic.com/_next/static/chunks/4093-be5a4b602dd5c78a.js" async=""></script><script src="https://cdn.theatlantic.com/_next/static/chunks/4219-ddc90b3d511b84e6.js" async=""></script><script src="https://cdn.theatlantic.com/_next/static/chunks/926-0fae957bf31b0a36.js" async=""></script><script src="https://cdn.theatlantic.com/_next/static/chunks/8322-953eb68d75c58cc6.js" async=""></script><script src="https://cdn.theatlantic.com/_next/static/chunks/1066-93aa99a342a17433.js" async=""></script><script src="https://cdn.theatlantic.com/_next/static/chunks/8634-e46cb95aa95ded3e.js" async=""></script><script src="https://cdn.theatlantic.com/_next/static/chunks/pages/%5Bchannel%5D/archive/%5Byear%5D/%5Bmonth%5D/%5Bslug%5D/%5Bid%5D-c0e53763bbf4b5ea.js" async=""></script><script src="https://cdn.theatlantic.com/_next/static/69tsob48ZMDbtI0c_5sg3/_buildManifest.js" async=""></script><script src="https://cdn.theatlantic.com/_next/static/69tsob48ZMDbtI0c_5sg3/_ssgManifest.js" async=""></script><script>window.__CF$cv$params={r:'a3937d405bc61a78',t:'MTc4OTA5NjMzMA==',u:'01a08e7384587613b14c479bb2bc103b',ut:'nSoWDgZuTG14Cf9HANuLRG0A4V27EkP1Uji_3r8nT24-1789096330-1.2.1.1-KFWRsXt3rdV04uxFUvYuhfYV5ZFdDzNJa_P63_8x0sryYOD1zS93RZNP6Uh86IWgz1197JYPbwy9JYEN1fwicyd_Ffyehnc8ROhF8jSubn4',i:60};(function(){if(!document.body)return;var s=document.createElement('script');s.src='/cdn-cgi/challenge-platform/scripts/precursor/main.js';document.head.appendChild(s);})();</script></body></html>