I've touched on this topic before, but feel that it bears repeating...
In a sense programmers are like playwrights... We write scripts to guide actors.
When our scripts are run on a production system, just as when a play is performed before a live audience, unscripted things may happen.
It's the responses to those unscripted things that we need to think about.
Unscripted things are really common in the business environment, so those of you who writescripts programs that run in business environments already know what I'm going to say... It's pretty much a fool's errand to "code for everything".
Open up the topic "What can possibly go wrong?" in a requirement gathering session, and your nice clean functional specification will quickly grow from a few pages to several volumes. If you're in the business process domain, using BPMN for modeling, your nice clean process flow diagram quickly begins to resemble a plate of spaghetti.
This increase in complexity by it's very nature is disturbing... but perhaps more disturbing is the likelihood that your solution will become very brittle. The more you handle (if done wrong) the more likely you are to introduce side-effects and conflicts.
This brings to mind this quote from Blaise Pascal:
So what's my point? Our programs execute in the real world, and in the real world unscripted things happen, and we've got to deal with those unscripted things... Don't we?
Drum roll please...
No. We programmers do not have to deal with those unscripted things.
Go into any business office during a normal work day and more than likely you are going to witness a lot of unscripted activity. The lion's share of the events that are taking place are routine - maybe even mundane - but stick around for awhile and you'll likely hear a stressed out or raised voice conversation. Many times those are in reaction to unscripted events.
When the unscripted happens in the business workplace, the Knowledge Workers do exactly what Actors do when the unscripted happens while performing a play... They ad-lib.
A prop crashes to the floor... A quick witted actor responds (while staying in character)... His quick witted comrades play off his response (while staying in character) and together they guide the ad-libbed activity back towards the original script - The play must go on.
Our lesson from this - or at least my take on it - is that programmers don't have to try to deal with unscripted things. Instead, we need to recognize that ultimately it's people who are going to have to deal with the unscripted - not our code.
With this in mind, it becomes a bit more clear that our task is to empower the users - the Knowledge Workers - to deal with the unexpected.
Something bad happens... A Knowledge Worker responds...
What are the tools and the options that the Knowledge Worker needs to examine the situation, intervene to make a change, and get the show back on the road? What do your Knowledge Workers need to effectively ad-lib their lines?
Figure that out and supply those tools to your Knowledge Workers and we'll have made progress.
For those of you who still aren't quite satisfied with leaving others to clean up a mess that you could have avoided... Let's go a bit further.
Instrument the "ad-libbing" tools that you give your Knowledge Workers. Capture the ad-libbed work that's going on... analyze the effectiveness of what transpired... cogitate on how useful it would be to incorporate these responses into your own code... and now you're truly on the path of continuous improvement.
In a sense programmers are like playwrights... We write scripts to guide actors.
When our scripts are run on a production system, just as when a play is performed before a live audience, unscripted things may happen.
It's the responses to those unscripted things that we need to think about.
Unscripted things are really common in the business environment, so those of you who write
Open up the topic "What can possibly go wrong?" in a requirement gathering session, and your nice clean functional specification will quickly grow from a few pages to several volumes. If you're in the business process domain, using BPMN for modeling, your nice clean process flow diagram quickly begins to resemble a plate of spaghetti.
This increase in complexity by it's very nature is disturbing... but perhaps more disturbing is the likelihood that your solution will become very brittle. The more you handle (if done wrong) the more likely you are to introduce side-effects and conflicts.
This brings to mind this quote from Blaise Pascal:
"Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte."
"I have made this longer than usual because I have not had time to make it shorter."I interpret the meaning as "a short but well written script is more accurate than a long rambling one"...
So what's my point? Our programs execute in the real world, and in the real world unscripted things happen, and we've got to deal with those unscripted things... Don't we?
Drum roll please...
No. We programmers do not have to deal with those unscripted things.
Go into any business office during a normal work day and more than likely you are going to witness a lot of unscripted activity. The lion's share of the events that are taking place are routine - maybe even mundane - but stick around for awhile and you'll likely hear a stressed out or raised voice conversation. Many times those are in reaction to unscripted events.
When the unscripted happens in the business workplace, the Knowledge Workers do exactly what Actors do when the unscripted happens while performing a play... They ad-lib.
A prop crashes to the floor... A quick witted actor responds (while staying in character)... His quick witted comrades play off his response (while staying in character) and together they guide the ad-libbed activity back towards the original script - The play must go on.
Our lesson from this - or at least my take on it - is that programmers don't have to try to deal with unscripted things. Instead, we need to recognize that ultimately it's people who are going to have to deal with the unscripted - not our code.
With this in mind, it becomes a bit more clear that our task is to empower the users - the Knowledge Workers - to deal with the unexpected.
Something bad happens... A Knowledge Worker responds...
What are the tools and the options that the Knowledge Worker needs to examine the situation, intervene to make a change, and get the show back on the road? What do your Knowledge Workers need to effectively ad-lib their lines?
Figure that out and supply those tools to your Knowledge Workers and we'll have made progress.
For those of you who still aren't quite satisfied with leaving others to clean up a mess that you could have avoided... Let's go a bit further.
Instrument the "ad-libbing" tools that you give your Knowledge Workers. Capture the ad-libbed work that's going on... analyze the effectiveness of what transpired... cogitate on how useful it would be to incorporate these responses into your own code... and now you're truly on the path of continuous improvement.
