Mr. Mc''''''Kittrick, after very careful consideration, sir, I've come to the conclusion 
 that your new defense system '''sucks'''. -- Gen. Beringer, ''WarGames''
----

'''Context:''' You have a tedious, repetitive, and mission critical task that is currently performed manually by humans. The nature of the task is that either not doing it, doing it incorrectly, or doing it when it is not needed are fatal errors.

'''Problem:''' One of the standard arguments for automation is that it reduces the chance of user error, but some tasks are sufficiently drastic that it's not safe to have a program decide whether to carry them out.

'''Forces:''' The engineering point of view is to automate it, and code it so well that it cannot fail. Whether or not this is feasible, business stakeholders are uncomfortable with automation, because of machine or programmer fallibility. If the task is carried out incorrectly, end users may be adversely affected (causing tangible damage) or lose faith in the business solution (causing intangible damage).

'''Solution:''' Let the automated process determine what should be done, but instead of doing it, present a report of what is to be done to a human, who can decide whether or not to "pull the trigger" and commit the transaction.
----
Examples of this pattern:
	* The MicrosoftWindows Disk Cleanup wizard, which determines which files on a computer are likely to be unneeded, but doesn't actually delete them; instead, it presents the user with the option to delete them, compress them, or do nothing
	* Nightly report generation, in which sensitive nightly reports are exposed to customers. An automated process can create the reports, and a user can verify that the reports were generated correctly and look reasonable before publishing them to customers. (This assumes that the reports are easily verifiable by a human and not by a machine; this may not always be the case).
----
This is a sort of proto-pattern, eh? Pretty good one, too.

''Most "DesignPatterns" are really "construction patterns". I'd like to see a PatternLanguage that's centered around higher-level design issues. Some of these are already known, like the PrincipleOfLeastSurprise. Any others?

''The PatternLanguagesOfProgramDesign books have a number of higher-level patterns.''
----

I believe that the first example is actually an AntiPattern, which I can't come up with a very good name for just now. Extremely few humans have any chance at all of answering the questions asked by the MicrosoftWindows Disk Cleanup wizard. It typically asks whether I want it to delete the file ''''''CVQShrFOO.dll'''''', which I generally have no idea what is for.

''JoelSpolsky had an article about the same issue, but in the dialog Windows raises the first time you access an online help file. "First, I'm going to build an index for the help file you're about to access. Would you like a big index or a little index?" Ummm... I just want to look this up!''
----
As an ExceptionThatProvesTheRule....

NASA's Space Shuttle used automation for some of what was previously manually initiated. So they overbuilt their software and the system: They used five computers doing the same thing and voting on a course of action. Also, their software is coded so as to have the least number of bugs possible - quite possibly the least number of bugs for software of their complexity in the world. Yet both accidents involving loss-of-life with the shuttle were due in large part to judgement calls by humans. Correct?

''No, the rule does not fail in this case since you still don't want those kinds go/no-go in the hands of computers, even if humans fail at them sometimes, because the performance of the humans (imperfect though it be) is still expected to be better than a computer.'' 

Read http://www.fastcompany.com/online/06/writestuff.html

----
Preamble: ThreeStrikesAndYouAutomate