Steps in the right direction –

Advice for an existing project becoming Agile.

Emily Bache

AstraZeneca R&D, 431 83 Mölndal, Sweden

emily.bache@astrazeneca.com

Introduction

This paper presents one concrete technique (problem/solution pair) I employ in my day to day work here at AstraZeneca, and one problem that I am currently wrestling with. I took over responsibility for code maintenance and development for the C-Lab project in August 2002 and have been gradually introducing XP practices as needed since then. [1]

1. Automating maintenance tasks: checklist-to-script

As part of taking over the C-Lab project, I needed to learn how to do maintenance tasks such as adding help files, updating calculation modules and also making new releases to the production environment. These tasks were not difficult, they just involved many manual steps – “move this file here”, “edit this file to switch off debug log statements” etc. All the knowledge about what to do was in someone’s head, so I started by just going through it with them, and we wrote a basic checklist of what to do for each task. 

The thing with a checklist is that it changes every time you do the procedure, as you learn better ways to do it, and write scripts to automate the boring parts (as recommended by the “Pragmatic Programmer”[2] in the section about ubiquitous automation). I started using a technique I learnt at my last job [3] which is to employ a little process to keep the checklist updated, and eventually to get rid of it altogether. 

 

The idea is that when you use a checklist, you print it out and physically note down on it things that you do differently as you learn better ways to perform the task, and write scripts to automate parts of it. The other part to it is to incorporate into the checklist a process to keep the electronic copy of the checklist updated.  

  1. Step one of your checklist: Find the printed checklist with notes from the last time you did the task. Incorporate any relevant changes into the master electronic copy

  2. Step two on your checklist: print it out.

  3. As you go through the checklist, think about how to automate steps in it, and begin writing scripts to do so.

  4. As you do things differently from what the checklist says, physically write on it what you actually do, as you do it. Names and locations of scripts, parameters etc. Otherwise just tick items off the list as you do them.

  5. Archive the paper copy of the checklist ready for the next time you do the task, or for when something goes wrong with your script and you need to find out how you did it manually before.

  6. Eventually you have a redundant checklist, it just says “(1) run xyz script.” Then you can probably throw away the checklist.

 

Comments

I find it’s better to scribble notes on paper than to try to update the electronic copy immediately. Somehow it seems to preserve more information, be more flexible, and is harder to lose on a small screen with many overlapping windows. Also note, I haven't managed to automate away any of my checklists yet. But they are getting shorter. The other thing I'm unsure of is how this would work with a larger team - would someone else on my team understand my scribblings from last time when they came to do the task? I imagine it would be fine if I were there to be asked for clarification.

I’m hoping that others at the workshop will give me feedback about whether this concrete strategy is useful to them, and if so will try it out and help me to improve it.

 

2. Design

The code I inherited had a fairly good, (straightforward, understandable), design, which I was happy to take on. There were awkward corners, of course, and I needed to add new functionality, so the design clearly needed to evolve. One prerequisite for that is automated tests, and I have been fairly successful at adding those, and the other thing you need is to be skilled at design and refactoring. I'm finding that day to day design improvement to be the hardest thing I do. Most of the literature seems to imply that so long as you are writing unit tests first, good design kind of comes about naturally, and I'm not finding that at all. You have to know what to refactor to. You need to be able to not only spot duplication, but know what to do about it. You have to be able to competently apply Kent's rules for simple design [4] So, how do you improve your design skills? What do you do, other than writing tests first? I have a few ideas, but I'm interested to hear what others in the group have found helpful.

 

I guess I'm looking for advice about where to concentrate my energies. Bear in mind I'm currently the only developer on my project, but I'm hoping the team will grow to two or three by the autumn.  

 

References

[1] I have written about this experience more generally in a practitioners report/poster, “Building software for scientists – a report about incremental adoption of XP”, also published at XP2003.

[2] “The Pragmatic Programmer”, Hunt, Thomas

[3] I originally learnt this technique from my (then) colleague, Martin Erlandsson, (martin.erlandsson@guide.se).

[4] from XP explained:

[5] Joshua Kerievsky is currently writing a book about this, I'm sure he'll be pleased I pointed it out :-).

[6] I'm thinking of tools that turn your code into class and sequence diagrams, then you edit the diagrams and the code is changed in sync.

[7] Scott Ambler talks about this kind of group modeling with a whiteboard in this book "Agile Modeling"

[8] As advocated by Dave Thomas , (analogous to playing scales when learning a musical instrument, I think).