Manual processes can fail due to human error and take time that a person could use for other things. Therefore, automate processes. A good automated process requires minimal human intervention and operates correctly and consistently.
Resulting Forces:
- Automating processes can take a lot of time. Consider the amount of time saved and the errors prevented before automating.
- A process that has been automated is harder to change than one which hasn't. As a result, there's a natural desire not to change automated processes, even when they need it. Either actively combat this resistance to change, or only automate processes which have a low need for change.
- The results of an automated process are often assumed by users to be correct. Consider the need for continuous or periodic inspection of the results, especially when the inputs to the process change in some essential way. (And consider automated inspection as well.)
Examples:
- AutomatedBuild
- AutomatedTesting
- AutomatedDeployment
- AutomatedCodeGeneration
- AutomatedCodeInspection
See also:
In my experience, automation is plagued by the EightyTwentyRule. A hybrid approach may be better for smaller projects where automation assists for a majority of the repetitious work, but hand-tuning is used for the rest. Abstractions are a powerful but vengeful and capricious beast.
CategoryAutomated CategoryProtoPattern