Recap of Sep 12 Work Session

Attendees were Steve, Jordan, and Adnan. This was the beginning of an iteration, Jordan had been out of the loop for a while, and Adnan is still pretty new to the team, so we spent an extra long time in the planning meeting. From our previous iterations, the estimated velocity for this iteration was 1.5, up from 1 after the previous 2-week iteration. To lay out the plan for the remainder of the release, we alternated 1 story, 2 stories for each iteration column to the end of the release.

In the course of the discussion, we relized we had incorrectly prioritized the "Basic Standard Error Handler" story too low. We all had different ideas of what needs to be in a basic standard error handler, how the standard blocks should interleave with the user's code, etc. Because of this, we decided to first have Jordan and Adnan pair on this story, picking up where I had left off with fresh eyes. Meanwhile, I worked on fixing the bug that I found after the last iteration.

As you may recall, the bug I found was that one of our earliest stories - list all macros and calls was no longer working. The symptom was that the feature was implemented when we were analyzing test modules the metacode system project itself to generate the lists, and subsequently moved the modules out into other projects to be analyzed by our own project. No code tests broke when we changed that, but since our lister form had no way for the user to select a project to read, it was not functional and returned only empty lists.

So, on the standard error handler, the work was somewhat frustrating and disheartening. The point of this project is to create tools to make it easier to do better quality software engineering in VB/VBA/Access, and the metacode system seemed like a great place to start, primarily as an aid to standardizing error handling and allowing the error handling system to be changed easily. The disheartening part is how messy the cleanest standard error handling system we've been able to come up with really is.

The problem is exascerbated by the need for opening and closing tags around the expanded sections to allow for re-expansion, and we ended up with no less than 5 separate sections per procedure to allow for all the reasonable customizations a user might need to do. Furthermore, the metacode system design, as it is now, gives no way to add comments in the sections between the tagged blocks to indicate what the programmer should put there. Attempts at clever work-arounds were thwarted by the fact that error braching and resuming has to be done all within the same procedure and can't be delegated to a called procedure.

We figured out it would help a lot (though still be pretty darned messy) if the metacode system allowed for named custom sections within macros that could have default text, so the first time the macro is expanded, the custom section can be generated with a default comment telling the user what to put in the tag. When regenerating, the text previously in the named custom section would be retained and placed back in the same named custom section, thus preserving the user's customizations. This also would allow an error handler macro to consist of only a single macro definition with one custom code section that could contain the entire original procedure body when seeding the code, along with custom sections for special case error handling code. We had briefly discussed this kind of thing in planning sessions before, but didn't think we had a compelling need, so we never fleshed it out this far. Needless to say, we have a compelling need now, and we added another story card to the stack.

We have chosen to still call the "Basic Standard Error Macros" done because we're hoping that yet another fresh look at it can come up with a cleaner way to handle all the same requriements.

So - back to the bug fix. I had thought this was a bug that crept in in spite of pretty much full test coverage, but I was wrong. When I dug into the problem, I found that the form was calling a method of the model that had no tests, and that any tests of this method would have broken when we moved the test modules out of the metacode project itself. I can't figure out how this happened because I haven't seen anyone on the team breaking the rules, but this does seem to be an isolated case, so I just added the test that should have been there, and commenced making it pass. It took a while, but when I finally figured out what needed to be done, it was just a few lines of change. Once this test passed, I fixed the user form by simply making it a tab page on the form we build for simple preview since it aldready had a file selector and a way to call to the metacode system after the file is selected. This merging when pretty smoothly and again, only requried a few lines of code to make work, once I figured out which lines.

OK, so once I finished the bug fix, I switched back to the "Standard Error Macros" to finish up as described above, and Jordan and Adnan went to work on the "Reexpand All Macros" story. We had thought that one would just work once we wrote the tests, but by the end of the session, it still wasn't quite working yet. We think we're pretty close, and it should be working early next session.