As I was leaving the training facility (<guild />) this afternoon, turning the key in my car's ignition, it broke off. Having a backup key somewhere hidden under the car would have been nice. No such luck. At least I had one at home, and access to public transportation.
What are the chances of such an event happening? I'd have been less surprised to find my battery dead. However upon polling a few peers, I found many had similar "ignition fail" stories, so the event is not that uncommon, is a contingency we might plan for. Or code for:
and so on.
Python has to be indented that way; the keywords are in blue. Just scanning the code reminds one of the "poetry" of starting one's car, and what failures (exceptions) might occur. One may use one's imagination to further extend the code.
We've designed coding languages to model businesses, to where we might now play "what if" games (simulations) using code as a medium of expression.
The point is not so much to run such code, although it adds to readability if it's grammatically runnable. The point is to use code as a way of giving shape to our thoughts about risk management.
"When we try to do X, what might happen instead, and what ways do we have to handle or cope with these eventualities?" Consider modeling your answer using try / except syntax. Use the grammar of a computer language to tell the stories.
With ISO 9001 2015, "risk management" takes center stage, replacing "preventative measures" as where to focus. The try / except syntax of modern computer languages, common to more than just Python, suggests that language designers have baked risk management into their very fabric.
Computer programs need to deal with the same fact businesses do, that their surrounding world might be VUCA. Might we take advantage of these innovations? Might we sketch the workflows of a company in pseudo code (that runs)?
A secondary motive for modeling workflows, and risks, in simple code, is to bolster our willingness to digest meaning in this form. Given the centrality of IT to so many businesses, the willingness to eyeball source code with comprehension, as a part of everyday business communications, is more than ever a worthwhile commitment.
Management and IT will more smoothly converge to the same page to the extent that high level memos reflect the way a business is actually implemented at the coding level. UML was a step in the right direction. Indeed, what I'm recommending here is already a fait accompli in some board rooms. The whiteboard is typically mix of diagrams and pseudo-coded objects, even when taking the ten thousand foot view.
As we move to assess risk and develop strategies for managing it, lets remember the positive feedback loop, the synergy, between our computer languages and the real world phenomena they strive to capture in running code. As with mathematical notations, of which these languages arguably form a part, once they have been applied to the reality we care about, our powers of imagination kick in and new possibilities open. A language about "what's so" grows to become a language of "what could be", as we bootstrap ourselves towards a better tomorrow.
As for me, I've learned I must make more backup car keys and keep them easily accessible.
