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'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.
About the author
Steve Berczuk is an engineer and ScrumMaster at Humedica where he's helping to build next-generation SaaS-based clinical informatics applications. The author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, he is a recognized expert in software configuration management and agile software development. Steve is passionate about helping teams work effectively to produce quality software. He has an M.S. in operations research from Stanford University and an S.B. in Electrical Engineering from MIT, and is a certified, practicing ScrumMaster. Contact Steve at steve@berczuk.com or visit berczuk.com and follow his blog at blog.berczuk.com.
