I recently wrote a short article on on StickyMinds.com about automation. After it was published I came across another related post by Jim Coplien which makes the point that automation should come after you have figured out your process.
I recently wrote a short article on on StickyMinds.com titled, "Automation: Process Comes." After it was published I came across another related post by Jim Coplien which makes the point that automation should come after you have figured out your process.
I'm not sure that Jim and I disagree in principle on anything related to when to automate, but I wanted to make one point. I think it's important to start out an process that is likely to be automated with the idea of automation in mind. If you don't, you are likely to make decisions that are both not important to getting your work done and which would make automation harder to implement. As I've said before in the context of deployment, the sooner you consider your constraints the easier it will be to build a system that addresses your real problems.
The hard thing is identifying which "requirements" are there out of expediency (or perhaps laziness) and which are there out of need. Having an iterative approach to any kind of automation can help you with this. Do a process, write a script to do it, then once the script works well, figure out how to get the script to work more "automatically."
Your process model should come first, before you consider tools, or even automation. But you can benefit by building automation into the process early, and iteratively improving it.
