Dependency Tasks
I am a big fan of Pat Kua's tiny tasks and to see my desk would be to believe that there had been an invasion of yellow stickies on the planet.
Pat explains the idea on his website but to summarise; the idea is that given a story, you break it down into the individual tasks that need to be done in order for it to be complete, write each tasks on a sticky and then when that task is finished throw the sticky away.
This has really well for me because I am inclined to lose focus/get distracted and having a list of tasks that I need to do helps keep me on track.
This week it has come to me that perhaps the metaphor needs to be extended slightly. There have been a couple of occasions when I have been working on something and I complete all the tasks I needed to, but then I break something else which was reliant on something that I changed.
The work I'm doing is in the build area so the idea of having a suite of tests to protect me from making that mistake is not there.
My immediate thought is that along with writing the tiny tasks I should also write some dependency tasks which will help me to recognise what things are reliant on the story I am doing, and therefore allow me to either make the necessary changes in these areas or just not break them!
In a way I suppose this is just an extension of the idea of tiny tasks but for me it requires a bigger picture look at how what I'm doing effects the rest of the world and therefore it makes sense for me to view the two things separately right now.
I'm going to give this idea a try and report back on how it's worked out. Hopefully it will stop me breaking things quite so much. As always any ideas are welcome.
"The work I'm doing is in the build area so the idea of having a suite of tests to protect me from making that mistake is not there."
Perhaps you should have a suite of tests. This is something I decided to try the next time I end up as a build monkey. I find that a lot of build tasks have a programmatically assertable behaviour. I just don't think that people have opened up to the idea of TDD for the build system.
Part of that reason could be Ant. Ant tries to deceive you into thinking that setting up a build can be a declarative process. It's really scripting though, and better done using a language like Ruby/Rake.
Kris Kemper
13 Aug 08 at 1:51 pm
Yeh this is something I've been considering, but like you say with ant it's quite hard to do and we couldn't think of a good way to do it without making it take twice as long to do.
I've only briefly looked at Ruby/Rake…would it be just as easy as testing Ruby code to write tests around your build? I imagine it probably would be but I've never tried it.
What sort of things would you imagine would be tested out of interest? The creation/deletion of directories, that the tests were actually run? Just trying to think how you would get the most benefit out of using this approach as I'm sure it could be useful.
Mark Needham
13 Aug 08 at 9:01 pm
Hi Mark,
Glad you're still using Tiny Tasks. Although we used them on our project to break down functional tasks, we did use them, albeit less occasionally, for identifying any dependencies.
Normally I would treat them as higher priority as I see integration points a higher risk, especially if it breaks existing behaviour.
On a different note, when I have refactored build scripts in the past, I would normally write manual test scripts (scenarios written down in a text pad). I think the payback for automating them is less, though I can still manually step through them and ensure I haven't broken any existing functionality.
Pat
14 Aug 08 at 9:17 am