19 lines
33 KiB
HTML
19 lines
33 KiB
HTML
<!doctype html><html><head><meta charset=utf-8><title>Interview with Dr. David D. Woods - Increment</title><meta name=description content='Resilience engineering pioneer Dr. David D. Woods discusses reliability and resilience engineering, graceful extensibility, and how to engineer complex, performant software systems.'><link rel=canonical href=http://localhost:3000/reliability/resilience-engineering-david-woods/ ><link rel=apple-touch-icon-precomposed href=/img/icon-571805a1.png><meta property=og:title content='Interview: Dr. David D. Woods – Increment: Reliability'><meta property=og:url content=http://localhost:3000/reliability/resilience-engineering-david-woods/ ><meta property=og:description content='A discussion of the distinctions (and dependencies) between reliability and resilience, and how to build complex systems that perform under strain and surprise.'><meta property=og:image content='https://images.ctfassets.net/3njn2qm7rrbs/6Q3D0w8nis0u66FQeCTjbg/843b26ce0013258589c76a15a49461d4/cover-issue16.png?w=1000'><meta name=twitter:card content=summary_large_image><meta name=twitter:image content='https://images.ctfassets.net/3njn2qm7rrbs/6Q3D0w8nis0u66FQeCTjbg/843b26ce0013258589c76a15a49461d4/cover-issue16.png?w=1000'><meta name=twitter:site content=@IncrementMag><meta name=twitter:title content='Interview: Dr. David D. Woods – Increment: Reliability'><meta name=twitter:description content='A discussion of the distinctions (and dependencies) between reliability and resilience, and how to build complex systems that perform under strain and surprise.'><link rel=alternate type=application/rss+xml title=Increment href=/feed.xml><meta name=viewport content='width=device-width,initial-scale=1'><link rel=preload href=/fonts/baton-turbo/400-30a55d66.woff2 as=font type=font/woff2 crossorigin=anonymous><link rel=preload href=/fonts/baton-turbo/500-1603c0e8.woff2 as=font type=font/woff2 crossorigin=anonymous><link rel=preload href=/fonts/tiempos-text/400-c4810745.woff2 as=font type=font/woff2 crossorigin=anonymous><link rel=preload href=/fonts/tiempos-head/700-383ede62.woff2 as=font type=font/woff2 crossorigin=anonymous><link rel=stylesheet type=text/css href=/css/bundle-289d885f.css><link rel=stylesheet type=text/css href=/css/issues/16-c2b7b183.css><script>// Don't fade art if it loads ~instantly
|
||
setTimeout(()=>{document.documentElement.classList.add('fadeArt')},250);</script><script defer src=/js/defer-737fbd90.js></script><script>const INCREMENT_META={issueNumber:16,issueSlug:'reliability',articleSlug:'resilience-engineering-david-woods'};</script></head><body class='Issue_reliability Article_resilience-engineering-david-woods'><nav class=PageNav><div class=u-Container><div class=column><h1 class=logo><a href=/ ><img src=/img/logo-ae2c55d5.svg alt=Increment></a></h1><a class=out-now href=https://store.increment.com/ style=color:#595959><div class='IssueTitle tiny'><div class='t-Caps meta tiny'><span>NEW</span></div><h3 class='t-IssueTitle title'>Buy the print edition</h3></div></a><ul class=nav><li><a href=/issues/ ><span>Issues</span></a></li><li><a href=/topics/ ><span>Topics</span></a></li><li><a href=https://store.increment.com/ ><span>Store</span></a></li><li><a href=/about/ ><span>About</span></a></li></ul></div></div></nav><div class=ArticlePage itemscope itemtype=http://schema.org/Article><script type=application/ld+json>{
|
||
"@context": "http://schema.org",
|
||
"@type": "Article",
|
||
"headline": "Interview: Dr. David D. Woods",
|
||
"image": " https://images.ctfassets.net/3njn2qm7rrbs/6Q3D0w8nis0u66FQeCTjbg/843b26ce0013258589c76a15a49461d4/cover-issue16.png?w=1000",
|
||
"datePublished": "Thu, 25 Feb 2021 19:00:00 GMT",
|
||
"dateModified": "Thu, 25 Feb 2021 19:00:00 GMT",
|
||
"publisher": {
|
||
"@type": "Organization",
|
||
"name": "Increment",
|
||
"logo": {
|
||
"@type": "ImageObject",
|
||
"url": "https://increment.com/img/logo.png"
|
||
}
|
||
},
|
||
"description": "A discussion of the distinctions (and dependencies) between reliability and resilience, and how to build complex systems that perform under strain and surprise.",
|
||
"mainEntityOfPage": "http://localhost:3000/reliability/resilience-engineering-david-woods/"
|
||
}</script><header class='u-Container ArticleHeader'><div class=column><div class=u-Grid><div class=main><h4 class='t-Byline byline large'><a href=#authors class=j-SmoothScroll itemprop=author><span>Ipsita Agarwal</span></a></h4><h1 class='t-TitleSerif large title' itemprop=name>Interview: Dr. David D. Woods</h1><div class='t-BodySans large intro' itemprop=description>A discussion of the distinctions (and dependencies) between reliability and resilience, and how to build complex systems that perform under strain and surprise.</div></div><a class=issue href=/reliability/ ><span class='t-Caps tiny part-of'>Part of</span><div class='IssueTitle small' style=color:#863051><div class='t-Caps meta'><span>Issue 16</span> <span>February 2021</span></div><h2 class='t-IssueTitle title'>Reliability</h2></div></a></div></div></header><div class='u-Container ArticleContent'><article class='ContentBody column' itemprop=articleBody><div class=ArticleLayout><p>Technological systems, like society, are becoming ever more complex—with interdependencies that are difficult to trace, operating in environments that inevitably find their edges. Resilience engineering posits that to be dynamic, systems must be able to extend their capabilities gracefully and adapt their capacities when needed.</p><p>We sat down with Dr. David D. Woods, who helped found resilience engineering in the early 2000s in response to several NASA accidents, including the Space Shuttle Columbia disaster, for which he was an advising investigator. For 40 years Dr. Woods has worked to improve the safety of complex, high-risk systems in fields such as aviation, nuclear power, and critical care medicine. In this conversation, he explains the concepts behind resilience engineering through the lens of the COVID-19 pandemic and other real-world crises, and how we can build systems that can perform even under stress and surprise.</p><p class=small><i>This interview has been edited and condensed for length and clarity.</i></p></div><div class='ArticleLayout interview'><p><strong>Increment:</strong><i><strong> What’s the difference between reliability and resilience as it relates to complex systems? In my experience, these terms get confused easily and often.</strong></i></p><blockquote><p><b>Dr. David D. Woods:</b> Reliability is a record from the past—we can pull out different facets of how we’ve performed in the past and say we’re getting better on this criterion or that. The problem is that [reliability] makes the assumption that the future will be just like the past. That assumption doesn’t hold because there are two facts about this universe that are unavoidable: There are finite resources and things change.</p><p></p></blockquote><blockquote><p>Finite resources and change mean that the future will not be like the past. You need to be poised to adapt, and [you can’t do that] by just trying to invest in reliability. You have to think about robustness and resilience. Robustness then becomes: Can you make the system not just more optimal or productive but able to withstand known risks? If you understand a threat, how do you make the system robust so it will continue to work—or work in a gracefully degrading mode—in the face of that threat?</p></blockquote><blockquote><p>Now we’re getting to what really is at the heart of resilience, and that’s extensibility. How do you extend performance when an event challenges the way you usually work, challenges your boundaries? Events will arise which stress your system. Those events will find the edges in your plans for normal operation and in your contingency plans, [so] you need to find ways to stretch at those edges. Resilience as extensibility is the opposite of brittle reliability.</p></blockquote><blockquote><p>We build sources for extensibility to be able to extend performance when we <i>don’t</i> understand what the challenge is. We rely on a lot of cognitive, human, and collaborative mechanisms. NASA Mission Control practiced anomalies on space shuttles for the Apollo era all the time. In space, surprise is normal. [They weren’t practicing a] specific failure. They were practicing how to have extensive resilience in the face of an event they hadn’t [anticipated]. They were practicing teamwork.</p></blockquote><p><i><strong>System failures can arise from a combination of smaller component failures or the environment being complex and unpredictable. And yet there’s this persistent idea that we have to become better at predicting, modeling, and potentially excusing failure if the chances of that failure happening are very low. How do you make the case for true surprises?</strong></i></p><blockquote><p>The first way to approach surprise is from a reliability and robustness point of view, [in which surprise is] about the way consequences and frequency combine. If it’s low frequency [and the consequences are low], it doesn’t matter. If the consequences are high and it’s low frequency, then we need to do something. For example, [the nuclear power industry] was worried about this in the ’70s given public concern about radiation. [Nuclear accidents] are estimated to be very low-frequency events, but because they can be so catastrophic, you’re going to make a big effort to be prepared to handle them.</p></blockquote><blockquote><p>It’s a frequency-consequence combination. Everybody assumes that frequency just declines, that we have a normal distribution and the tail is small. But it turns out, in statistics, [we] look at what’s called heavy-tail distributions. We often underestimate what looked like low-frequency events. They’re actually much higher frequency than you think because the tails are heavy.</p></blockquote><blockquote><p>An example is Hurricane Harvey in Houston, Texas, a couple of years ago. That was the third year in a row that Houston had a “one-in-500–year” flood event. If you say [what we’re expecting] is a one-in-100–year flood event and you’re looking at a specific geographic location, the frequency data might [suggest that]. But now take space and time averaging. In the continental U.S. this year, how many one-in-100–year flood events will happen? There will be multiple one-in-100–year flood events this year, and that number is increasing. So you have to better prepare.</p></blockquote><blockquote><p>We screw frequency up because we get trapped in linear simplifications, and we miss trends of change in the world. And that is not remotely good enough.</p></blockquote><blockquote><p>The science underlying resilience says there’s a different kind of surprise, and that’s the dominant form we care about: model surprise. In other words, because of finite resources and change, you’re adapting to the world and trying to get a better match between your capabilities and the world you’re in. The possibility for the mismatch to grow, or to move around, is fundamental. You can think of this as an envelope: [Your system is] successful within that envelope, but it has boundaries. The boundaries move. They’re not static.</p></blockquote><blockquote><p>Model surprise will happen because the world keeps changing. So, very simply stated, viability [of a system] in the long run requires extensibility. The world will throw challenges that find the edges in your current system. If you can’t extend performance at the edges, you’ll end up with a brittle collapse.</p></blockquote><p><i><strong>Can we look at an example that demonstrates brittle reliability versus graceful extensibility in the way the COVID-19 pandemic was handled?</strong></i></p><blockquote><p>We saw a classic form of resilient performance extensibility in the early stage [of the pandemic]. With the novelty of the disease, there was a lot of uncertainty about the proper kind of care: Do you put [patients] on ventilators quickly or delay [doing so] even though their oxygen saturation is low? The guidelines before COVID suggested that you respond aggressively to low oxygen saturation in the blood. But [health care workers] had to learn that that could be an over-response. An ad hoc, informal communication network rapidly emerged among physicians trying to develop and understand how to best treat patients. These physicians had a readiness to revise and a readiness to respond.</p></blockquote><blockquote><p>For an example of brittleness, in [early spring 2020] the CDC was struggling with the novelty [of the disease] and trying to integrate information and send guidance to hospital systems about how to deal with [it]. But what happened? The CDC was sending updated guidance to hospitals multiple times a day. The problem that hospital systems had was how to keep up with these changing recommendations.</p></blockquote><blockquote><p>[Government jurisdictions and hospital systems] just weren’t set up as dynamic organizations, whereas an emergency room in a hospital is set up to be very dynamic. Viability requires extensibility. And extensibility has to be built before you’re in the challenge or change situation. Generating this capability during the change is much more difficult than if you generate it in advance.</p></blockquote><p><i><strong>Extensibility is a dynamic capability: We have to be able to design a system in such a way that it can adapt in advance of a crunch by anticipating that crunch. How does anticipation work? What’s the distinction between anticipation and modeling for brittle reliable systems and contingency planning?</strong></i></p><blockquote><p>Anticipation turns out to be critical. The classic result is anticipating a bottleneck or crunch, so you act now in order to generate the resources or response capability before the bottleneck hits you. This originally came from studies on how people adapt to high workload, like anesthesiologists who did dynamic stuff in an operating room. They were highly sensitive [to change]. The [absolute] probability of a crunch happening might be low, but they picked up signs that the probability had gotten higher.</p></blockquote><blockquote><p>People [tend to] discount evidence that challenges their model. Their model is being surprised by events in the world, but instead of being ready to revise, they discount the evidence. It’s [about] how sensitive you are to the emerging information that things don’t fit your model. If you’re waiting for definitive evidence that some new problem has arisen, the problem will be much bigger before you act.</p></blockquote><blockquote><p>Instead, the people who were good [at adapting] were sensitive. They were picking up early evidence that things might be different, so they monitored new channels. They interacted with other people to pick up what information they had. They changed their effort. Anticipation is very tightly connected to a readiness to revise.</p></blockquote><p><i><strong>You’ve previously written that every unit in a system, at whatever scale, has to have non-zero graceful extensibility. What do you mean by that?</strong></i></p><blockquote><p>If you have zero extensibility you’re maximally brittle. A unit can’t have enough [graceful extensibility] by itself.</p></blockquote><blockquote><p>To use a hospital example, in no unit—a clinician or clinician team—can we have enough ICU capability. No unit by itself can have sufficient graceful extensibility given the possibility for model surprise. And the reason is the same: finite resources and change. This is why an emergency room has the capability to adapt to patient crises, but only so much. At some point in a mass-casualty event it needs help from the rest of the hospital system in order to handle all the patients. It needs more personnel, it needs to expand the space it takes [up], it needs to facilitate interactions with the diagnostic centers in the hospital. So you have to have other interdependent units, and they have to be ready to adapt to help the unit at risk of getting crunched.</p></blockquote><blockquote><p>As I start to run out of the capacity to act as the situation continues to deteriorate, I need help from somebody who’s in the neighborhood, so to speak. The neighboring units parallel or above, sometimes even below in a network or a hierarchy, need to recognize I’m at risk of saturation and do something to help me.</p></blockquote><blockquote><p>You can see the breakdown of [extensibility] in the pandemic response. Early in the pandemic, some governors and states got slammed. They were quickly trying to get the public to cooperate with restrictions because they were afraid of overloading their hospitals. They got better cooperation because everyone [realized] we don’t want to have our hospitals look like Italy or New York. Then, once hospitals were able to adapt or it didn’t get that bad for certain jurisdictions, everybody went, “See, we don’t want to do this anymore, it’s not that bad,” and cooperation with activity restrictions dropped off.</p></blockquote><blockquote><p>That’s an example of what we call reciprocity. Without reciprocity, you can’t get that second layer of, “I have some graceful extensibility, but as I start to run out of capability, I need other parties to help me.”</p></blockquote><p><i><strong>What would you say to someone who reads this interview and says, “Alright, I understand the concept of resilience. I understand that my system has to have graceful extensibility. Where do I start?”</strong></i></p><blockquote><p>That’s contingent on the engineering system and the role they’re dealing with. The pursuit of efficiency—faster, better, cheaper—inadvertently undermines the sources of resilient performance. So the general advice is [to adopt] pragmatic but different engineering [practices]. It’s the balance between seeking optimality in the short run and building and investing in graceful extensibility [in the long run]. Those have to be balanced—they interact, they’re interdependent, and you need both.</p></blockquote></div></article></div><div class='u-Container ArticleFooter'><div class=column><div class='u-Grid ContentBody small content'><div class=authors id=authors><div><div class=photo><figure style='background-image:url(https://images.ctfassets.net/3njn2qm7rrbs/65lITnIK7c3P6QuHEbmlo9/e8f8e7124eda5a0fac6e8b76af1ebe05/Ipsita_Agarwal.jpeg?w=500)'></figure></div><div class=text><h4>About the author</h4><p><b>Ipsita Agarwal</b> is a narrative nonfiction writer and engineer whose debut book will be published by Trapeze. She has written for publications including <i>Wired</i> and <i>Smithsonian </i>and is a contributing editor for Stripe Press.</p><p><a href=https://twitter.com/ipsitaag target=_blank>@ipsitaag</a></p></div></div></div><div class=topics><div class=text><h4>Topics</h4><p><a href=/topics/interviews/ >Interviews & Surveys</a></p></div></div></div></div></div></div><div class=SubscribeBox><a id=newsletter class=anchor href=#newsletter></a><div class='ContentBody inverted store'><div class=u-Container><div class='u-Grid column'><div class=box style=background:#4c70b1><div class=text><h2>Buy the print edition</h2><p class=j-TextBalance>Visit the Increment Store to purchase print issues.</p><p><a class='t-Caps u-Arrow' href=https://store.increment.com/ >Store</a></p></div><a href=https://store.increment.com/ class=magazine><figure class=j-MaskedImage data-fill=/art/19/19-cutout-1000-7ffb5dba.png data-mask=/art/19/fill-cms-1000-83522f38.png></figure></a></div></div></div></div><div class='ContentBody email'><div class=u-Container><div class='u-Grid column'><div class='j-EmailForm box' style='box-shadow:0 -5px 0 #4c70b1'></div></div></div></div></div><div class=ContinueReading><div class=u-Container><div class=column><h2 class='t-Caps xlarge'>Continue Reading</h2><ul class='u-Grid articles'><li class='ArticleBlock footer' style=color:#863051><a class=j-Preload href=/reliability/resilience-as-adaptability-freshworks/ ><div class='IssueTitle tiny' style=color:#863051><div class='t-Caps meta'><span>16</span></div><h3 class='t-IssueTitle title'>Reliability</h3></div><div class=text><div class=head><h4 class='t-Byline byline'><span>Ipsita Agarwal</span></h4><h3 class='t-TitleSans title'>Case study: Resilience as adaptability at Freshworks</h3></div><div class='t-BodySerif small intro'>The company’s disaster preparedness plan, developed in the aftermath of a devastating cyclone, enabled it to adapt and endure during a global pandemic.</div></div></a></li><li class='ArticleBlock footer' style=color:#439eab><a class=j-Preload href=/mobile/claire-sibthorpe-interview/ ><div class='IssueTitle tiny' style=color:#439eab><div class='t-Caps meta'><span>18</span></div><h3 class='t-IssueTitle title'>Mobile</h3></div><div class=text><div class=head><h4 class='t-Byline byline'><span>Ipsita Agarwal</span></h4><h3 class='t-TitleSans title'>Interview: Claire Sibthorpe</h3></div><div class='t-BodySerif small intro'>The GSM Association’s head of connected women, connected society, and assistive technology discusses the impact mobile devices have had on the lives of marginalized women and what technology companies can do to further mobile equity.</div></div></a></li><li class='ArticleBlock footer' style=color:#4c70b1><a class=j-Preload href=/planning/planning-in-public-at-youtrack/ ><div class='IssueTitle tiny' style=color:#4c70b1><div class='t-Caps meta'><span>19</span></div><h3 class='t-IssueTitle title'>Planning</h3></div><div class=text><div class=head><h4 class='t-Byline byline'><span>Ipsita Agarwal</span></h4><h3 class='t-TitleSans title'>On planning in public</h3></div><div class='t-BodySerif small intro'>YouTrack’s Elena Pishkova shares how the team plans products in public view and in collaboration with customers.</div></div></a></li><li class='ArticleBlock footer' style=color:#e89e00><a class=j-Preload href=/testing/a-test-of-meaning/ ><div class='IssueTitle tiny' style=color:#e89e00><div class='t-Caps meta'><span>10</span></div><h3 class='t-IssueTitle title'>Testing</h3></div><div class=text><div class=head><h4 class='t-Byline byline'><span>Ipsita Agarwal</span></h4><h3 class='t-TitleSans title'>A test of meaning</h3></div><div class='t-BodySerif small intro'>For AARP, AutoCAD, Google, and Pinterest, qualitative research can include everything from focus groups to hand-drawn maps.</div></div></a></li><li class='ArticleBlock footer' style=color:#40af9e><a class=j-Preload href=/software-architecture/case-studies-in-rearchitecting/ ><div class='IssueTitle tiny' style=color:#40af9e><div class='t-Caps meta'><span>12</span></div><h3 class='t-IssueTitle title'>Software Architecture</h3></div><div class=text><div class=head><h4 class='t-Byline byline'><span>Ipsita Agarwal</span></h4><h3 class='t-TitleSans title'>Case studies in rearchitecting</h3></div><div class='t-BodySerif small intro'>How Buffer, ThoughtWorks, N26, and Zapier have shifted their software to respond to new contexts and met new needs.</div></div></a></li><li class='ArticleBlock footer' style=color:#5ebe92><a class=j-Preload href=/frontend/case-study-web-components-for-screen-readers/ ><div class='IssueTitle tiny' style=color:#5ebe92><div class='t-Caps meta'><span>13</span></div><h3 class='t-IssueTitle title'>Frontend</h3></div><div class=text><div class=head><h4 class='t-Byline byline'><span>Ipsita Agarwal</span></h4><h3 class='t-TitleSans title'>Case study: Web components for screen readers</h3></div><div class='t-BodySerif small intro'>How Slack changed the way it designs accessible frontend components.</div></div></a></li><li class='ArticleBlock footer' style=color:#5ebe92><a class=j-Preload href=/frontend/case-study-mobile-payments-in-india/ ><div class='IssueTitle tiny' style=color:#5ebe92><div class='t-Caps meta'><span>13</span></div><h3 class='t-IssueTitle title'>Frontend</h3></div><div class=text><div class=head><h4 class='t-Byline byline'><span>Ipsita Agarwal</span></h4><h3 class='t-TitleSans title'>Case study: Mobile payments in India</h3></div><div class='t-BodySerif small intro'>How Google designed an app for users from big cities to rural areas on devices old and new.</div></div></a></li><li class='ArticleBlock footer' style=color:#29386a><a class=j-Preload href=/remote/building-remotely-auth0-automattic-basecamp/ ><div class='IssueTitle tiny' style=color:#29386a><div class='t-Caps meta'><span>15</span></div><h3 class='t-IssueTitle title'>Remote</h3></div><div class=text><div class=head><h4 class='t-Byline byline'><span>Ipsita Agarwal</span></h4><h3 class='t-TitleSans title'>Case studies in building remotely</h3></div><div class='t-BodySerif small intro'>Lessons in building, supporting, and growing remote and distributed teams from Automattic, Auth0, and Basecamp.</div></div></a></li><li class='ArticleBlock footer' style=color:#443d79><a class=j-Preload href=/containers/containerization-case-study/ ><div class='IssueTitle tiny' style=color:#443d79><div class='t-Caps meta'><span>17</span></div><h3 class='t-IssueTitle title'>Containers</h3></div><div class=text><div class=head><h4 class='t-Byline byline'><span>Ipsita Agarwal</span></h4><h3 class='t-TitleSans title'>Case study: Launching an open government platform in Taiwan</h3></div><div class='t-BodySerif small intro'>By enlisting an open-source project with an innovative approach to containerization, Audrey Tang built a singular digital forum.</div></div></a></li></ul><h3 class='t-Caps large'>Explore Topics</h3><ul class='t-BodySerif large topics'><li><a href=/topics/learn/ >Learn Something New</a></li><li><a href=/topics/scaling/ >Scaling & Growth</a></li><li><a href=/topics/ask-an-expert/ >Ask an Expert</a></li><li><a href=/topics/interviews/ >Interviews & Surveys</a></li><li><a href=/topics/guides/ >Guides & Best Practices</a></li><li><a href=/topics/opinion/ >Essays & Opinion</a></li><li><a href=/topics/culture/ >Workplace & Culture</a></li></ul><h3 class='t-Caps large'>All Issues</h3><ul class=issues><li><a href=/planning/ ><div class='IssueTitle large' style=color:#4c70b1><div class='t-Caps meta'><span>Issue 19</span> <span>November 2021</span></div><h1 class='t-IssueTitle title'>Planning</h1></div></a></li><li><a href=/mobile/ ><div class='IssueTitle large' style=color:#439eab><div class='t-Caps meta'><span>Issue 18</span> <span>August 2021</span></div><h1 class='t-IssueTitle title'>Mobile</h1></div></a></li><li><a href=/containers/ ><div class='IssueTitle large' style=color:#443d79><div class='t-Caps meta'><span>Issue 17</span> <span>May 2021</span></div><h1 class='t-IssueTitle title'>Containers</h1></div></a></li><li><a href=/reliability/ ><div class='IssueTitle large' style=color:#863051><div class='t-Caps meta'><span>Issue 16</span> <span>February 2021</span></div><h1 class='t-IssueTitle title'>Reliability</h1></div></a></li><li><a href=/remote/ ><div class='IssueTitle large' style=color:#29386a><div class='t-Caps meta'><span>Issue 15</span> <span>November 2020</span></div><h1 class='t-IssueTitle title'>Remote</h1></div></a></li><li><a href=/apis/ ><div class='IssueTitle large' style=color:#00afbe><div class='t-Caps meta'><span>Issue 14</span> <span>August 2020</span></div><h1 class='t-IssueTitle title'>APIs</h1></div></a></li><li><a href=/frontend/ ><div class='IssueTitle large' style=color:#5ebe92><div class='t-Caps meta'><span>Issue 13</span> <span>May 2020</span></div><h1 class='t-IssueTitle title'>Frontend</h1></div></a></li><li><a href=/software-architecture/ ><div class='IssueTitle large' style=color:#40af9e><div class='t-Caps meta'><span>Issue 12</span> <span>February 2020</span></div><h1 class='t-IssueTitle title'>Software Architecture</h1></div></a></li><li><a href=/teams/ ><div class='IssueTitle large' style=color:#8e65bf><div class='t-Caps meta'><span>Issue 11</span> <span>November 2019</span></div><h1 class='t-IssueTitle title'>Teams</h1></div></a></li><li><a href=/testing/ ><div class='IssueTitle large' style=color:#e89e00><div class='t-Caps meta'><span>Issue 10</span> <span>August 2019</span></div><h1 class='t-IssueTitle title'>Testing</h1></div></a></li><li><a href=/open-source/ ><div class='IssueTitle large' style=color:#4a5ad3><div class='t-Caps meta'><span>Issue 9</span> <span>May 2019</span></div><h1 class='t-IssueTitle title'>Open Source</h1></div></a></li><li><a href=/internationalization/ ><div class='IssueTitle large' style=color:#c096ca><div class='t-Caps meta'><span>Issue 8</span> <span>February 2019</span></div><h1 class='t-IssueTitle title'>Internationalization</h1></div></a></li><li><a href=/security/ ><div class='IssueTitle large' style=color:#4dbac5><div class='t-Caps meta'><span>Issue 7</span> <span>October 2018</span></div><h1 class='t-IssueTitle title'>Security</h1></div></a></li><li><a href=/documentation/ ><div class='IssueTitle large' style=color:#f5684d><div class='t-Caps meta'><span>Issue 6</span> <span>August 2018</span></div><h1 class='t-IssueTitle title'>Documentation</h1></div></a></li><li><a href=/programming-languages/ ><div class='IssueTitle large' style=color:#d69336><div class='t-Caps meta'><span>Issue 5</span> <span>April 2018</span></div><h1 class='t-IssueTitle title'>Programming Languages</h1></div></a></li><li><a href=/energy-environment/ ><div class='IssueTitle large' style=color:#d6658e><div class='t-Caps meta'><span>Issue 4</span> <span>February 2018</span></div><h1 class='t-IssueTitle title'>Energy & Environment</h1></div></a></li><li><a href=/development/ ><div class='IssueTitle large' style=color:#53a88e><div class='t-Caps meta'><span>Issue 3</span> <span>October 2017</span></div><h1 class='t-IssueTitle title'>Development</h1></div></a></li><li><a href=/cloud/ ><div class='IssueTitle large' style=color:#707aed><div class='t-Caps meta'><span>Issue 2</span> <span>July 2017</span></div><h1 class='t-IssueTitle title'>Cloud</h1></div></a></li><li><a href=/on-call/ ><div class='IssueTitle large' style=color:#ef766e><div class='t-Caps meta'><span>Issue 1</span> <span>April 2017</span></div><h1 class='t-IssueTitle title'>On-Call</h1></div></a></li></ul></div></div></div><footer class=PageFooter><div class='u-Container ContentBody small'><svg style=display:none><symbol id=twitterIcon viewBox='0 0 32 32'><path d='M32.1 6c-1.2.5-2.5.9-3.8 1 1.4-.8 2.4-2.1 2.9-3.6-1.3.8-2.7 1.3-4.2 1.6a6.8 6.8 0 0 0-4.8-2c-3.6 0-6.6 3-6.6 6.6 0 .5.1 1 .2 1.5-5.5-.3-10.4-3-13.6-6.9-.6 1-.9 2.1-.9 3.3 0 2.3 1.2 4.3 2.9 5.5-1.1 0-2.1-.3-3-.8v.1c0 3.2 2.3 5.9 5.3 6.5-.6.2-1.1.2-1.7.2-.4 0-.8 0-1.2-.1.8 2.6 3.3 4.5 6.2 4.6-2.3 1.8-5.1 2.8-8.2 2.8-.5 0-1.1 0-1.6-.1C2.9 28 6.3 29 10 29c12.1 0 18.7-10 18.7-18.7v-.9c1.4-.9 2.5-2 3.4-3.4z' fill=currentColor /></symbol><symbol id=facebookIcon viewBox='0 0 32 32'><path d='M30.2 0H1.8C.8 0 0 .8 0 1.8v28.5c0 1 .8 1.8 1.8 1.8h15.3V19.6h-4.2v-4.8h4.2v-3.6c0-4.1 2.5-6.4 6.2-6.4 1.8 0 3.3.2 3.7.2v4.3h-2.6c-2 0-2.4 1-2.4 2.4v3.1h4.8l-.6 4.8H22V32h8.2c1 0 1.8-.8 1.8-1.8V1.8c0-1-.8-1.8-1.8-1.8z' fill=currentColor /></symbol><symbol id=rssIcon viewBox='0 0 32 32'><path d='M10.7 25.6c0 2.4-2 4.4-4.4 4.4S2 28 2 25.6s2-4.4 4.4-4.4 4.3 2 4.3 4.4zM6.1 2c-.6 0-1.3 0-2 .1-1.3.1-2.2 1.2-2.1 2.4.1 1.2 1.2 2.2 2.4 2.1.6 0 1.1-.1 1.6-.1 10.7 0 19.4 8.7 19.4 19.4 0 .5 0 1-.1 1.6-.1 1.2.8 2.3 2.1 2.4h.2c1.2 0 2.1-.9 2.2-2.1.1-.7.1-1.4.1-2C30 12.7 19.3 2 6.1 2zm-.7 9.6c-.4 0-.8 0-1.3.1-1.3.1-2.2 1.2-2.1 2.5.1 1.3 1.2 2.2 2.5 2.1h.9c5.7 0 10.4 4.7 10.4 10.4v.9c-.1 1.3.8 2.4 2.1 2.5h.2c1.2 0 2.2-.9 2.3-2.1 0-.4.1-.8.1-1.2-.1-8.4-6.9-15.2-15.1-15.2z' fill=currentColor /></symbol><symbol id=linkedInIcon viewBox='0 0 32 32'><path d='M29.6,0H2.4C1.1,0,0,1,0,2.3v27.4C0,31,1.1,32,2.4,32h27.3c1.3,0,2.4-1,2.4-2.3V2.3C32,1,30.9,0,29.6,0z M9.5,27.3H4.7V12 h4.8V27.3z M7.1,9.9c-1.5,0-2.8-1.2-2.8-2.8c0-1.5,1.2-2.8,2.8-2.8c1.5,0,2.8,1.2,2.8,2.8C9.9,8.7,8.6,9.9,7.1,9.9z M27.3,27.3 h-4.7v-7.4c0-1.8,0-4-2.5-4c-2.5,0-2.8,1.9-2.8,3.9v7.6h-4.7V12H17v2.1h0.1c0.6-1.2,2.2-2.5,4.5-2.5c4.8,0,5.7,3.2,5.7,7.3V27.3z' fill=currentColor /></symbol></svg><div class='column main'><section class=social><a href=https://twitter.com/incrementmag class=twitter><svg viewBox='0 0 32 32'><use xlink:href=#twitterIcon x=0 y=0></use></svg> <span>@incrementmag</span> </a><a href=https://facebook.com/incrementmag class=facebook><svg viewBox='0 0 32 32'><use xlink:href=#facebookIcon x=0 y=0></use></svg> <span>incrementmag</span> </a><a href=/feed.xml class=rss><svg viewBox='0 0 32 32'><use xlink:href=#rssIcon x=0 y=0></use></svg> <span>RSS Feed</span></a></section><section><h4>About</h4><p><em>Increment</em> is a print and digital magazine about how teams build and operate software systems at scale. <a href=/about/ >Learn more</a></p></section><section><h4>Work with us</h4><p>Interested in joining the team at Stripe? <a href=https://stripe.com/jobs>View job openings</a></p></section></div><p class='column copyright'><span>© 2022 <em>Increment</em></span> <a href=https://stripe.com>Published by Stripe</a> <a href=https://stripe.com/privacy/media-policy>Privacy policy</a></p></div></footer></body></html> |