Partial Work Session Recap Aug 22

We had two new team members showing up this week (for a total of five -- maybe someday we can have an even number), so we took an extra hour or so for discussion at the beginning of the session to bring them up to speed on the project, talk about the planning process, and generally ask lots of questions. We did start getting into implementation discussions about specific cards, but this was quite worthwhile, since time spent thinking about any aspect of the project seemed to help people get into the proper headspace for working on it. (Also, I tried to gently play topic cop. Perhaps I need a hat, or maybe just an Armenian cucumber.)

During the initial discussion, Steve proposed extending our iteration time to two weeks in order to have some kind of velocity to measure. Given that this effectively means we have two-day iterations, this seemed perfectly reasonable. (Although, I'm not quite sure how this will work with such a long period between coding sessions. Having the initial meeting has been really useful at getting me back into the groove.)

Anyway, after wrapping up our discussion and a quick demo of VBLiteUnit, it was lunchtime already. When we got back, we split up... and as I only worked with Kristie today, Steve will have to post his recap of what everyone else was doing.

Kristie and I picked the "context parameters" story card and got to work. While this might not have been the ideal place to start a new member, she quickly got into it when we started refactoring the existing tests. Task #1 was to move all of our testing out to an external project. This allowed us to remove the last call to the evil "CreateModuleCallParserAndDestroyModule," and restored our ability to use the debugger (yaaaay!).

Cleaner tests in hand, we added much of the plumbing to the VbModuleLineReader class that will be necessary to finish this card. We wrote some code that was incomplete (i.e., it only worked on Subs and Functions, and not on Get/Set/Let statements). Knowing that, we got a little overconfident and tried to write a test at the end of the day that was too big. This got us considerably bogged down. Then, rolling this back turned into more of a pain, since the number of changes we'd made between the last green light and the time we decided to roll back exceeded the capacity of the Undo buffer in the VB editor. Source code control to the rescue... except that we weren't using it, because we don't have licenses to VSS and the ODE tools. Oops.

Perhaps another team task should be to implement a (relatively) simple source-code helper in Access which can transfer code from VBA modules to textfiles and vice versa, so we can use one of the various text-oriented source code control systems on it. (Or, one of us can do this between sessions in our copious spare time. Hm... perhaps I'll spike this if I have a free hour or two.)

When I left, Steve was working on integrating the various teams' work -- something else we'll have to learn how to do more efficiently and frequently throughout our workdays.

(Working with a new team member also raised two other issues for me: first, that we should agree on and document our code formatting standards -- indentation, capitalization, use of Hungarian notation, commenting, etc -- for hobgoblin's sake; and second, that it's amazing the kinds of things one learns from pairing. I got to teach another team member about Ctrl+Space, and learned a useful and really obvious trick for marking code for later deletion.)

One of the topics continually being raised is how Access makes it annoying and/or difficult to implement so many "best practices" like using source code control... or, come to think of it, handling errors. ;> Perhaps when we're done with this code generation tool, if we want to continue, we can continue developing other tools to make managing code in Access as much fun as developing database apps in it.