I have a couple of strategies for this that I'm including in The Productive Programmer book. First, make sure you timebox your efforts. Even if the end result of the timebox is that you create another one (because you've made such good progress), that prevents the automation from turning in to a week-long exercise when you thought it would just take 1/2 a day. Timeboxing also cuts down on the inevitable yak shaving that goes on anytime you start experimenting with something you haven't done before.
Automation is all about risk mitigation. For the thing you are thinking about automating, ask yourself the following questions:
- How long does it take to do it by hand now?
- How many times are you going to have to do it before the end of the project?
- What is the consequence of doing it wrong one time (i.e., forgetting a crucial step)?
If you take the product of the first item (how long does it take now) times the second (how many times are you going to have to do it), that tells you what kind of time investment you have now. If that time investment is longer than what it would take you to automate it, no brainer again: automate it. The third item is about risk mitigation: if it's disastrous if you miss a step, that should make you lean towards automating it. For example, I was on a project not long ago where (for bizarre historical reasons) they didn't want to separate the compiled versions of their tests between unit, functional, and integration. Their solution was to create hand-crafted test suites. But, that means that we have to remember to add them by hand every time we created new ones. That's a big risk: I'm never going to remember that! Instead, we automated it by creating a little Groovy script that ran at build time to auto-generate the test suites based on the root directories. The risk of not automating this problem was wasted time: we wrote a test and forgot to include it by hand, meaning that we don't get the benefit of the test and thus wasted the time it took to write it.
I'm curious if others have tried-and-true strategies for justifying automation...
1 comment:
To be good at automation you have to be good at a scripting language like Groovy or Ruby, or at a bare minimum...Ant. If you can't whip something up with one of those without using a ton of brain power, then you probably cannot automate. In my experience, most Java programmers aren't familiar with Groovy or Ruby so I will occasionally see something done with Ant but even that's pretty rare.
It's a shame that so many are missing out on some great automation tools by not learning a scripting language. I was able to whip up a Groovy log parser that supported wild-carded arguments and had to be context aware as well as being able to parse XML that was dumped into the logs. This took 30 minutes. The same thing in Java would have taken me at least a day, probably two, and would have been the furthest thing from "fun".
Granted that's not an automation example in the same vein that you have mentioned since this parser only needed to be run once but it would have been extremely time consuming to do it manually and thus it was worthy of automation.
Post a Comment