Recap of Work Session for Sept. 9th

For various reasons, only Adnan and myself were able to be at the work session this week, and if I remember correctly, it was only Adnan’s second session (possibly 3rd?) working on our project. Nevertheless, we made great progress, and finished the Simple Expand in Place story.

This was the end of an iteration, and we finished a story in addition to the story finished the previous week, giving us a velocity of 2 for the iteration, and raising our overall velocity from 1 to 1.5.

It’s during a session like this that some of the benefits of the Extreme Programming process really shine through:

1. There was no question of what stories needed to be worked on. We were in mid iteration, and there were open story cards from the previous session that were started and unfinished.

2. It was pretty clear where to pick up work on our chosen story. The last few tests and the todos at the end if the current test list showed us the direction development was going.

So, in spite of jumping in on a story we had not worked on in the previous session, and with one of us pretty new to the team and the project, we were still able to get productive right away.

Because we’ve been a bit lax on the refactoring steps (though improving), I tried to make sure we did refactoring after each change, and a little extra for catch-up. We factored the system for opening Access databases and working with their code projects and modules out into a separate VB project wrapper class, for one thing.

One issue we ran into was that the most convenient way to actually write the updated code out into the target project was to loop through the modules collection of an open instance of Access, call the code to perform metacode expansion on module one into a string, and write the new text back into the module. The code that performs metacode expansion on a module, though, was previously written to open its own instance of the same database, and that was causing a conflict. We refactored the code so that it only opens one instance of the VB project wrapper class, and passes it down the calling hierarchy. This also improves the speed a bit, which is nice since the tests were starting to get a bit slow. Of course, when you read things like “and passes it down the calling hierarchy”, you know there’s more refactoring that can be done, and I’m sure we’ll get to that as we go along.

We found one bug in a previously completed story that, because it’s a GUI issue, our unit tests did not catch. When we implemented List all Macros and Targets, we had the target modules in the same project as the metacode system, and we’ve since changed the system to work on external Access, VBA projects instead. We never went back, and added a way to select a project to read macros and targets from.

I’m wondering if there’s something currently in the GUI layer that could have been pushed down into code that would have caused a test to break when the Macro/Target List issue appeared (I can’t think of one myself, anyone?) Probably, this is something that should be documented as a user Acceptance Test, so it would be caught by manual testing. Currently, we have no system for user Acceptance Testing on this project, so this is something we probably need to discuss.

As far as fixing the bug, I imagine we can just roll it into the Simple Preview form as a separate tab or something, and use the file and module selectors that are already on the Simple Preview form.