(#16) If This Then That
“However beautiful the strategy, you should occasionally look at the results.”
What’s the big difference between a plan and a strategy? You never ever rely on a plan.
Famed computer scientist Margaret Hamilton standing next to the space mission code she led the development of.
There’s a famous photograph from the 1960s space race. The picture shows computer scientist Margaret Hamilton standing proud and smiling, next to a large pile of paper documents and soft-bound books. Like a delicate arrangement of wooden blocks, the paper pile stood as tall as Margaret herself. The paper represented the programs, code, math(s), and algorithms needed to design navigation systems for the Apollo space mission. A pile of paper, as tall as a person, full of computer code. Let’s put that in perspective:
I could write a short computer program, a plan for the computer to execute, that would:
1) open a new text file,
2) write some words in that file,
3) close the file, saving the new text inside.
My programmed plan to open, write in, and save a text file would take up no more than an A4 page, depending on how I chose to syntactically articulate it. So, why did Margaret Hamilton and her team need to produce a stack of space mission navigation code, thousands of sheets of A4 paper, as tall as Margaret? Because computer programs are all about strategies, not plans.
A programmer like Margaret Hamilton builds software by using a defined set of logical tools. The art of programming is then to use these tools to sew together patches of existing code and make something new. Something specific. It’s a video game, a word processor, a social media phone app, or maybe, just maybe, a lunar navigation system. And why is that a strategy and not a plan?
One of the main tools a programmer will use, the one that makes a programmer a strategist, is the ‘if statement’:
If condition A is satisfied, do X, but if condition A is not satisfied, or something else happens, condition B, do Y instead of X.
That sentence is pretty convoluted, but the same idea can be drawn in a flow diagram:
Simplified diagram showing the inner workings of an if statement.
What makes this programming tool so intriguing, so powerful, is this:
With an if statement, you are never just thinking about the thing you want to happen or the thing you think is most likely to happen. You’re considering what should happen instead if that first possibility doesn’t go as expected, when it doesn’t proceed as planned. With an if statement, you are encouraged, forced even, to think about contingency plans. In the programmer’s if statement, this consideration for other outcomes would be an else if, or just else.
If This Then That (IFTTT) is a software company that helps people connect their phone apps together for seamless workflows. If I like a YouTube song then IFTTT will add that song to a Spotify playlist. In general, beneath the curtain of the user interface, IFTTT creates little pockets of code (applets) that all do something like:
If A happens, then do X.
Else, if B happens, do Y.
The company uses the power of the if statement to create automated harmonies in digital life.
When Margaret Hamilton’s team were designing programs for piloted missions into space, they would have had if statements embedded in if statements, with back-up plans laced through every possible line of the code. That’s strategy. When you’re sending frail human frames into the vacuum of space in tin cans, you can’t afford mistakes (or bugs) in the code. The software cannot fail. You cannot rely on a plan, you need a strategy.
Chris Johnson, a professor of safety-critical software systems at the University of Glasgow, describes the no failure demands of safety software like this:
“…if you’re writing code for an aircraft, it’s kind of difficult to reboot it while it’s in flight. And many of the techniques that work for standard software don’t work in the environment of safety critical systems…I’d you have a million lines of code, how can you be sure that those million lines of code don’t contain a bug?”
Some 45 years after that famous photograph of Margaret Hamilton standing next to her team’s code was taken, I made the decision to teach myself how to code. I wanted to wield my own if statements. Since then, I’ve found that coding has done something rather magical to my mind. Learning to speak to a computer did more for me than automate the crunching of numbers. Writing computer programs helped me use if statements for my plans. It turned my plans into strategies.
Now, whenever I’m asked for help, I challenge team members to adopt strategic thinking wherever they can. When someone (a student, say) presents an idea or a plan, my first question back to them is:
“What else do you have in case this plan doesn’t work out? What scenarios have you thought about. If not this plan, then what?”
Without necessarily being conscious of it, this sort of programmatic thinking turns you into a strategist. If your plan doesn’t work, or the most likely thing doesn’t happen, you have back-up plans (else ifs) in place. You have back-ups to the back-ups, and many different ways to flow into the future.
The Swiss Cheese Model for safety showing how several layers of accident prevention line up before an incident occurs. It can and does happen.
Alas, not even the best strategy, accounting for every conceivable failure, is without weak points. In the world of safety and risk, James Reason developed the Swiss Cheese Model to show how many failures (holes in the cheese) need to align (as slices of cheese) before an accident occurs. In other words, the Swiss Cheese Model serves to show that, even though it is unlikely that all your contingency and preventative disaster plans will fail, fail they can. Fail they do. A strategy, not plan, is simply the best tool we have to reduce the risk of failure to as low as is feasible.
So, what if your plan goes wrong? What’s your strategy?