Technology, Creativity, Hacking, and Risk Assessment

My iPhone's been bugging me to update its apps. Scores of them. So I let it "Update All". Then, a few minutes later, I asked it to update to the latest iOS. I was cognizant the OS update would require the device to restart, interrupting the other process - the app update. Was this a problem?

"No," I quickly determined. But I noticed my mind doing a bunch of things to reach this conclusion.

My first thought was that both these iPhone processes have been largely unchanged for a decade. If they played badly together, it would have been noticed and fixed.

My second thought was that App Update was designed to roll with interruptions. Power interruptions, connection interruptions, restarts, etc. Knowing how programmers think, I understood that the two processes don't need to talk to each other. App Update will simply assume its subservient position when the gnarlier OS Update seizes control of the device. It will duck out of the way, and continue later...or, come to think of it, maybe not. App updating might not resume upon restart, but I can always resume it later.

What won't happen is my winding up stuck with zombie half-updated apps from an interrupted process. If that were a thing that happened, iPhones wouldn't work. So that potential peril point had surely been addressed eons ago. I know that the device doublechecks newly downloaded apps to ensure their integrity. And, again: App Update gracefully gets out of the way. My only downside would be needing to complete App Update later. Ni problema.

My next thought was more complicated, and more ominous. There was a minute risk of a freak condition no engineer had thought to address. App Update and OS Update each contain multiple user-invisible processes, and there is a sliver of a chance that some vulnerable component of App Update might collide with a vulnerable component of OS update, confusing the phone and creating Problems.

It's unthinkably unlikely. These processes are close to fully assured for safety because there's so little a user can do to surprise them (and, again, they don't need to ever talk to each other, anyway). Each is triggered by a simple start/stop command, like a light switch, so there's little terra incognita - potential interference or unpredictably shifting conditions.

I'll note, parenthetically, that you actually can mess up a light switch if you use it surprisingly - e.g. violently mashing it on/off over and over, especially if it's a cheap or old switch. And maybe you could burn out the bulb faster if you stood there flicking on/off/on/off 10,000 times. Even the simplest process can fail if you surprise it with behavior its designers hadn't anticipated.

Creativity is about defying expectation and behaving in unintended ways. So creative people perennially make themselves edge cases, conjuring surprises that designers never anticipated, which means they break stuff a lot - both deliberately and accidentally.

This makes us terrific software testers. In fact, that's a hobby of mine. I've helped programmers uncover problems with their code by mashing their switches 10,000 times, or pushing the down-volume button when they wouldn't have expected it, or dunking the device in chocolate milk, or a zillion other surprising moves normal users don't normally do. This helps them make their apps more robust. A programmer once told me, with great admiration, "Gosh, Jim, you could break anything!"

See here for how this all ties in with creativity, Groucho Marx, Banksy, and Kali the Goddess of Death.

The start/stop commands for App Update are non-physical, so an iphone, unlike a light switch, doesn't care if you sit there punching at it all day. And there's little confusion or surprise one can introduce into such a simple process. Rigid constraints and simplicity ensure predictable user behavior.

Turning this around for a moment, if you've ever watched engineers use technology, you've noticed that they do so carefully, like walking a tightrope. They have a deeply engrained sense that stepping off the path of normal operation (to any degree and in any way) might provoke crisis. A layman might conclude that engineers are oddly frightened of technology, but that's not it. They're immensely cautious because they know that everything is held together by spit and wires, designed to surprisingly narrow purpose.

In that last link, I wrote:  

"There is risk in making yourself an edge case. Parking lots, for example, are designed for slow driving. Those who navigate them at high speed will tend to have drivers crash into them, because anticipating really fast cars while backing out of parking spaces requires more violent neck-craning than most people apply."

So this isn't just a tech thing. It's true of any designed system. It might work out fine for a night or two to sleep on an air mattress perched upon your kitchen countertop, but it's risky, because there are potential failure points never anticipated by the designers of the air mattress nor the designers of the countertops. And the severity of failure is inherently unpredictable. Anywhere from mild annoyance to the implosion of the galaxy. At least theoretically.

As a child I loved it when calculator batteries ran low and began reporting that 2 + 2 = 0000101010 or whatever. Good times! That spirit is what made me (I hesitate to use the English language's most misunderstood word) a hacker. I don't steal data, I don't break into the Pentagon, I don't change all my grades to "A" in the school computer, and I don't wreak revenge on adversaries. Those are activities of criminals with tech expertise, some of whom might also be hackers. Hacking is a simple and beautiful thing. It's the mindset of being unable to resist using technology in unintended and surprising ways. Creativity + technology = hacking. In earlier eras, we called it "tinkering." And, hey, as in any human realm, assholes gonna asshole.

I'm hacking right now. I'm repurposing this "Blogger" platform to create a whole other thing. Do I really strike you as fitting the "blogger" mold? No, I've got something else in mind - something hard to name or to pin down - while I squat gleefully in this hokey environment like a virus subverting its host.

I was hacking in 1997 when I repurposed the still-new tools of web publishing for the supremely odd purpose of chronicling my eating ("What Jim Had for Dinner"). These days half the world blogs about food (the first popping kernel doesn't make the other kernels pop), but the first time's always a hack, inevitably perpetrated by a hacker. So stop hating on hackers! You need us! We blaze the trails!

There is absolutely good reason - and a long and storied tradition - of willingly making yourself an edge case...and breaking stuff in the process. That's what art's about (or should be about). Creativity is inherently destructive!

All these strands, god help me, run through my head as I decide whether it's ok to run App Update and OS Update concurrently. I recognize that it's almost surely safe; and that the less important process, App update, will probably be interrupted, but surely recover gracefully; and that, yes, there's a minuscule chance that obscure aspects of both processes might coincide to make my phone play only Mr. Magoo cartoons for all eternity (or, more likely, transform into an expensive and stylish brick), because I'm doing a somewhat less common thing, which inescapably leaves me on marginally thinner ice. But I chose not to worry about it.


Being intensely curious, I begin to consider how other types of people might approach this same question. I turn my hacker's eye toward their mental operation.

Novice: "What, you mean the phone's doing two things at once?"

Average User: "Better cancel the App Update. It's not worth taking the chance. Tech can be unpredictable. I've been hurt before."

Power User: "I trust Apple on this one. Both processes are highly iterated and work beautifully, and App Update is designed to robustly handle interruptions of various sorts. So whatever OS Update does to the phone, App Update should gracefully get out of its way."

Engineer: "Mostly agree with Power User, but she failed to recognize that some unanticipated portion of one process might conflict with some unanticipated portion of the other process, creating problems with no hard limits (i.e. phone bursting into flames is ridiculously unlikely but not completely impossible). Best to be safe, and not make yourself an edge case."

CEO Type: "Technically possible catastrophe is not a pragmatic risk when odds are this low. Don't sweat it."

I know people who still disinfect groceries because, early in COVID, a scientist demonstrated that COVID can survive a day or two on surfaces. The study shook up laymen, who didn't understand that detecting some small quantity of virus under laboratory conditions is an exceedingly far cry from contracting covid from an egg carton. The research didn't conclude that the world is crawling with potential infection. It merely delineated the range of what's technically possible. It should have surprised no one that cooties transfered to a slab of plastic or paper don't immediately vanish in a puff of smoke. This doesn't place us in a Michael Crichton thriller with deathly supervirus lurking positively everywhere.

The risk is virtually zero. You'd need a ragingly infected stock boy to recently smear gobs of snot all over the item you bought, and for your fingers (unwashed and un-disinfected) to pick up sufficient viral load AND transfer that load directly into your nasal cavity (didn't your mom teach you not to pick your nose?). And even then infection isn't assured, nor are symptoms inevitable if infection does arise. So it's more like your phone bursting into flames from updating apps while updating OS. Theoretically possible, but not a pragmatic risk.

I'm not super curious about the conclusions of novice, average user, power user, engineer, or CEO. Nor am I particularly interested in their reasoning. What fascinates me are the various perspectives. All are looking in completely different directions!

Novice views from the baseline perspective of "me and my cool but unfathomable device," with a hazy expectation that it will always work.

Average User views from the perspective of distrust. Bad experiences with technology have instilled a visceral unwillingness to refrain from getting "fancy". A burnt hand forever recoils from hot stoves.

Power User views from a high-level perspective.

Engineer views from a low-level perspective.

CEO Type views from a managerial perspective, broadly scanning the horizon - all component factors - to identify likely SNAFUs and assign a risk level. Focus is on the potential for individual minor human failures to aggregate, creating chaos....while avoiding the engineer/scientist's professional fascination with pragmatically irrelevant edge-case scenarios.

That last more nuanced style of consideration involves myriad agile reframings of perspective, whereas the novice, average user, power user, and engineer remain mostly fixed in their perspectives.


A lithe perspective staves off addiction, depression (also this), and can even save your life. But it also allows you to view the world more holistically by nimbly swiping through a multiplicity of framings impacting a given situation.

This facility underpins my chowhounding prowess. While others stand before restaurant windows poring over the menu, or querying Yelp for ratings, or hustling departing diners for their assessment, I'm less specifically immersed, considering the evidence and mentally swiping through jillions of micro-decisions (of design, of branding, of lighting, of pacing, etc.) by the forces behind the operation. I'm sensitively probing their perspective in order to gauge my risk level in venturing in for a bite!