# Engineering for the Extreme? — narration script

Runtime 6:19. Timecodes are when each chapter starts; the film's animation is keyed to these cue times, so a recorded voice-over should keep each line near its timecode.

## 0:00 · A laptop at the bottom of the world

- `0:01` Imagine opening your web app from Antarctica.
- `0:05` An IT worker for the U.S. Antarctic Program, who writes online as brr, spent fourteen months there: first at McMurdo Station on the coast, then at the South Pole.
- `0:19` Afterward, brr wrote about what the internet is like at the bottom of the world, and what our software does to the people who use it there.
- `0:29` This film follows that article, Engineering for Slow Internet. The stories and the numbers are theirs.

## 0:38 · Antarctica = Extreme (Network) Conditions

- `0:39` At McMurdo, nearly a thousand people, plus science projects and station operations, shared links with a combined speed of a few dozen megabits per second.
- `0:51` That's less than many single homes have, split a thousand ways.
- `0:57` Every request travels by satellite. A round trip to the United States takes about 750 ms. On home fiber, a nearby server answers in a few.
- `1:11` Speeds at a single laptop ranged from a couple of kilobits per second to 2 Mbps on a really good day.
- `1:20` At the Pole, the internet exists only while the satellites are above the horizon, and that window moves about four minutes earlier every day.
- `1:31` Add heavy packet loss, and sometimes a complete fifteen-second dropout every few minutes.

## 1:38 · Antarctica Can Be Everywhere?

- `1:38` You might think this is a problem for a few hundred scientists. It isn't.
- `1:44` Ships at sea, remote research sites, rural customers with poor wireless service, concertgoers at a venue with 10s of thousands of people hitting the same cell towers, people still forced to settle for dial-up, all these folks live with some version of brr's link.
- `2:04` Remember Ana on crowded hotel Wi-Fi, from the ladder film? Same problem; fortunately, hers is just temporary.

## 2:15 · Six bytes, twenty-six minutes

- `2:15` One enterprise collaboration app needed nearly 20 MB of JavaScript just to show its main screen.
- `2:24` Worse, it had a built-in deadline. If loading didn't finish in time, the app gave up and sent the user to an error page.
- `2:34` It took hours of retries. The load that finally worked made 809 requests and moved 51.4 MB over twenty-six and a half minutes.
- `2:48` All of it so that brr could send one message: a 1.8 KB request carrying six bytes of text.
- `3:00` The app worked fine on its developers' machines in their world; out in the harsh real world, it failed.

## 3:09 · Timeouts aren't constant

- `3:10` Many apps assume every request finishes quickly. One chat app gave its connection ten seconds to set up.
- `3:20` Over a congested satellite link, the handshakes alone could take longer than that. So the app failed, waited, and failed again, while the network was up the whole time.
- `3:33` A competing chat app kept working. It tried more than one way to connect, reused its connections, and stretched its timeouts to fit the network it actually had.

## 3:46 · Load Perfect or You Get Nothing

- `3:47` Then there are updates. Minor operating system patches ran from half a gigabyte to one and a half. Major upgrades could top six.
- `3:59` Many built-in downloaders had no pause button, no progress number, and no way to resume. Lose the connection, and the download started over from zero.
- `4:12` Some installers even fetched gigabytes more in the middle of installing, long after the download seemed done.
- `4:21` The best one brr found was Microsoft's updater for Office on the Mac: pause, cancel, progress, speed, time remaining, and graceful resumption.  Are you surprised it was Microsoft?  Brand reputation isn't always tied to engineering prowess.

## 4:41 · Get out of the way and let the bytes flow

- `4:41` The core advice fits in one line. If you can tell that bytes are flowing, and they are, leave them alone, no matter how slow.
- `4:51` When a request does fail, wait longer before the next try, not less. Find out what's actually broken, and tell the person what's happening.
- `5:02` Break big transfers into small pieces that can resume, and keep a plain download link for anyone who'd rather use a tool that can.
- `5:14` The bar, brr says, is the web browser itself, which already pauses, resumes, and shows its progress.

## 5:23 · Living the Performance Law

- `5:24` Everything in this film comes back to the Performance Law: send less data, less often, from nearby, and only when needed.
- `5:34` Twenty megabytes of JavaScript breaks the first part. A deadline that throws away finished work breaks the second, because the next try sends it all again.
- `5:46` Most of your visitors aren't at the South Pole. But on any given day, some of them are on a link that behaves like it.
- `5:55` Good engineers build not just for the happy path, but account for extremes.  Considering access from the bottom of the world is truly an extreme, but know that if you can make something work under those conditions, it will absolutely fly in better ones.