TDD and GUI issues

I have read repeatedly, and tend to go along with the idea that you pretty much don't try to do TDD on the GUI itself, but instead, code as much as possible of what the GUI needs, so the GUI itself doesn't have enough code to be worried about.
In our last session, we had the odd-man-out in our 3-person team work on the GUI, and since it was never worked on by a pair, I did some more work on it after the session last week, refactoring the code - oops, did I say code? Did I say refactor without tests?

I'm wondering if we didn't end up a bit too liberal in defining what was GUI in the context of not testing GUI. All the stuff that groups items and builds the treeview could be tested to see if data was grouped, and items put into the right places in the treeview's collection. That's not testing the "GUI" because that doesn't mean it actually "looks" right. It is testing presentation layer code under the GUI that's very much testable.

So, in the context of XP/TDD, should we...
A) Keep what we did, and say it's shallow enough to call "GUI" and live with it?
B) Call it a spike, and re-do it with better TDD?
C) Add tests to what we have?

Opinions from the team? Anyone else, feel free to chime in, too.

Version Control

I think we should, at least for now, abandon the ideas (mostly mine) on how to do effective version control without using the standard source code control integration hooks provided by Microsoft.

My original thinking had been to come up with a workable system that could also be used by contributors to our open source code who owned Access, but not the more expensive developer version with the add-in that allows VBA to interoperate with a version control system.

Since our code looks like it will soon have good reason to migrate to a VB project, I think that point becomes mostly moot. Our contributors will pretty much be poeple who have Visual Studio, and thus, have Source Code Control interoperability built-in.
Anyone who wants to submit code written in VBA just needs to convince one of us or a friend with VS to help merge it.

Planning Process

After last week, I'm thinking our tracking process definitely needs slightly higher resolution - perhaps, not much resolution. The story cards as they currently stand are not quite suffucient.

I think what we have now might actually be sufficient if we were working more than one day a week. As it is, there's a very real chance that by the first release, after roughly 5 weeks (days) of work, there will have been many weeks in which less than 1 story was completed. This would leave us still with a very high uncertainty of our average velocity all the way out to our first release point. I don't think merely adding a point rating to each story will help because there's still no milestone for how many points of an unfinished story have been completed. That would leave us in the classical "it's -still- almost done" cycle.

Options:
1. Use task cards
2. Split about 1/3 of the stories such that the average story size is a fair amount smaller.

Any other suggestions? Any opinions on which of the above (or other) approaches will be simplest and most effective? Also, how do we change our system, and also meaningfully preserve information from our tracking so far?

Feature and Direction Speculations and Suggestions

I keep coming up with future ideas that are too far off to plan for yet, and I know one person who visits this site who's always asking for things closely related to the project work in progress.

Here's a place for folks on the team to speculate about future possible features, and for folks not on the team to place feature requests.

July 24 Work Session Recap

[This post written by Sam]
Most notable feature of this session: we have a new member. Jordan is another developer with several years' experience in Access and VB, and joined us today. Despite the Mythical Man Month truism that "adding more people to a late project makes it later," we managed to be as productive as we might have without training a new member.

We spent the first 30-45 minutes going over the general concept of the project. Moving from the overview into our coding session, we started back in on the third card:

List All Macros & Targets

• from where
  
• understandable list

Since this was Jordan's first exposure to test-driven development, Steve spent some time explaining the use of his custom VBA test harness, and further acquainting Jordan with the functionality we've already developed. Because triplet programming didn't seem appealing, we rotated throughout the day, with a pair working on the code, and the "odd man out" working on UI prototypes.

At the end of the day, we still weren't done with the card we started on. The project is now properly finding all macros in a given VBA project (and adding similar functionality for finding targets should be quite easy). We also have some prototyped code for displaying the lists of macros and targets in a TreeView control.

Some observations:

• We'll probably have to work on our "elevator speech" explanation of what this project will do. A live demo will probably help greatly.
• It's difficult to maintain focus while bumping elbows with a programming pair -- the tendency is to want to jump into the discussion rather than do one's own solitary work. Having four team members might actually be better in this respect, since having one's own conversation might reduce the tendency to eavesdrop.
• Having completed two full cards in three sessions (for a velocity of 2/3) means our release will have less features than we'd hoped -- but even so, we'll have something that can be demonstrated at the next PAUG meeting.
• Our lower anticipated velocity (on day 1, we projected 3, last week, we projected 2, we're currently thinking 1) is clearly a result of enhanced optimism, but whether we're being optimistic about how much to put on a card, or how practical it is to try to do one-day iterations, or what we should be able to accomplish on just the third day, isn't clear to me.
• The unit tests are getting rather bulky, and are now beginning to smell somewhat of duplication. Also, since we've now got the system parsing macrodefs from the entire project (and since we can add a macro directly from code without resorting to parsing), some of the methods of smaller scope can probably have their visibility changed to Friend, so we can retain the unit tests but simplify the public interface for consumer applications. However, since Friend may not be available in VBA, this may be a natural point for us to switch the code over into VB6. (This will, naturally, impact our velocity.)
• Watching someone's introduction to TDD is infectiously fun. (=

General Links July-Aug 2004

Here's a place to post comments with miscellaneous links, directly or indirectly related to the project.

XP Episode

While we're posting links on things to do with XP, here's An Extreme Programming Episode, which I remember finding much more helpful in giving a quick, immersive introduction to the practices of XP than, say, this site. (=

Link to article on applying XP to VB6

Here's a link to an interesting article about a team familliar with XP asked to create a project that had to be in VB6. It's rather a different perspective than where the majority of the current team members are coming from, being familliar with MS Access, VBA, and VB6, and trying to apply XP.

http://www.exoftware.com/documents/XPVB_000.pdf

Oh - and let's not forget this venerable link:

http://c2.com/cgi/wiki?ExtremeProgrammingWithVisualBasic

TSI Soon Experiment Update

TSI Soon is a free Access COM Add-in that allows one Access database/project to make one function call to shut itself down, open another database, and optionally invoke a function in the other database, passing it a Variant parameter. I'm hoping I can use this as part of a simple version control system for Access database projects.

I tried an experiment to see if I could make a (backer-upper) database that can be invoked via TSI Soon, that would in turn make a backup of the original database (back-me-up), then reopen that original database again.

The first try worked for opening backer-upper from back-me-up, and backer-upper successfully copied back-me-up to a backup, but then it silently failed to reopen back-me-up, leaving an Access session with no database open.

I recalled that Access has a problem reopening a database too quickly after closing it since it actually still has a background process finishing the close-down process, so I added a form to backer-upper with a 3-second timer delay before trying to reopen back-me-up. That did fix the problem.

There were 2 issues to think about in all of this. First, the 3 second delay added to the time it already takes to load (backer-upper), then load (back-me-up) again is enough to be a slight inconvenience. Second, after making any calls to TSI Soon, Access will crash the next time you try to close it. I don't know if this symptom is due to something that could have other side effects, and I don't know if there are any side effects to the crash (there don't seem to be), but it's definitely clumsy in any case.

What's Going On?

[this post written by Sam]
For those of you stumbling across this blog on its own, here's a little background:

A little while back, Steve got this wacky idea to form a team for the purpose of learning an agile software development methodology. After some initial recruitment efforts, he and I met to decide what our first project should be. (As for the methodology, we're going with Extreme Programming, probably due in no small part to an auspicious score of team coach.)

We decided to start with a metacode system for VB and VBA. Essentially, this is a code [re]generation / macro expansion tool which will be capable of managing duplicated code. One of the first practical applications of the system will be to manage error-handling code, and to "retrofit" an existing VB application with a consistent error-handling mechanism (since VB's error handling can be somewhat clunky). This would make it similar to some of the functionality provided by MZTools, except that MZTools (a) doesn't regenerate and (b) only works on a single procedure at a time. This system may also be useful in bringing a sort of pseudo-inheritance to VB as well -- I personally can't see quite that far out yet, but it sounds great.

One of our short-term goals is to create a tool that we can demonstrate at an upcoming general meeting of the Portland Access User Group (we're hoping for August, but one of us should probably see if the main presentation slot's still open). This will accomplish at least two things for us: (1) we can use it as a recruitment tool, to attract more of the extremely talented PAUG members who we know are out there, and (2) it may get us an initial group of a few users who can begin giving us feedback, so we don't have to keep wearing both the customer and the developer hats.

On a longer-term basis, we hope to add some valuable experience to our resumes and some new tools (especially TDD, which I'm really enjoying) to our toolboxes. Who knows -- we might even wind up with the seed talent for a new company.

Looking for More Participants - and Team Name

To all visitors.

So far, the project described on this site has 2 full-time team members (1 full day per week) and one part time team member and head coach. To do this as a "true" eXtreme Programming project, we need enough participants to swap pairs, so I'm hoping we can get this up to at least 4 or 5 regular participants.

If you are within commuting distance of Lake Oswego, Oregon (just south of Portland) and would like to join our work sessions on Saturdays at 10:00 am, please post a comment here.

Also, the team is looking for a name. The latest idea we're throwing around is VBXT (VB eXtreme Team). If you have an opinion about this name or another name idea, we're all ears.

Thanks,

Steve Jorgensen

Recap of Work Session Saturday, July 17th, 2004

Recap of Access XP work session Saturday, July 17th, 2004
Written by Steve Jorgensen

Planning and tracking notes:

We've been a little clumsy at tracking and following the plan so far. In reviewing the cards from the prior week, we thought we had completed 2 stories, and part of a 3rd, but it turns out we had only done item 1 of 3 on the second story card. The cards were as follows:

I. Define a macro.
II. Define a macro call.
1. No parameters.
2. With parameters.
3. Context parameters.
III. List all macros and calls.
From Where
Understandable list.

Last week, we did I and II/1, but we somehow overlooked doing II/2-3. As for story III, we had finished tests to identify a macro definition, and to get the name from the definition.

During the week, Sam and Steve had a lot of customer-hat and developer-hat e-mail discussions about the metacode syntax specification and how we might proceed with the parser. It turns out we really didn't have the macro syntax specified well enough to do story II/2-3 yet at all, so we hashed that out, and hashed it out some more today for about the first hour. On the developer-hat side, we decided that, although the parser code was coming along slowly but nicely with our current approach of using custom VB code to do all of the parsing, with our syntax so much resembling XML, and with all the near-term (next few tests) and long-term additional details we expect, we'd be better off refactoring the code to have the MSXML library do most of our heavy lifting, and we should do that sooner rather than later.

So, it was hard to count completed stories from last week as an integer, but we called it (1 + 2 * 1/2) = 2. We adjusted our release plan for a velocity of 2 cards, and it still looked like a very respectable release. Also, we looked at the calendar, and there's one additional weekend available before the next PAUG meeting, so we could consider extending the release by one week, and still be plan to present what we have at the next PAUG meeting (uh, perhaps, we should tell our PAUG meeting coordinator that we're hoping to present something?)

Note that Steve was going to look into using a utility called TSI Soon by this week to help us get a slightly better version control process in place, but didn't get time to do that and to also work on the missing pieces of the metacode syntax specification. Hopefully by next week, he'll have time to see if TSI Soon will be useful to us to help with our version control process. The plan is that, since the TSI Soon add-in can, without closing Access, close one database, open another, and pass a variant argument to a procedure in the other database, we could set up another database that makes a copy of the one that invoked it, then reopens the original database by making another call to the TSI Soon add-in. Later, we can think about making our own add-in to do that more cleanly, but the TSI Soon method should work and be simple enough to implement.

Development Session:

We were going to start with refactoring the MSXML library into the code, but the test code from last week seemed messy enough that we decided to find a way to neaten that up first. We feel it is desirable to keep as much of the test material right in the test code as we can, but VB is not a great language for representing the medium-long text blocks we're feeding into the parser or validating against coming out of the parser, so we moved those items into an Access table. Ah yes, that is better.

Next, we started refactoring the MSXML library interface into the code. First, we had MSXML take over part of the work of parsing a macro body, then pretty much all of it except for the initial munging of the code for parsing by MSXML. Next, we refactored the code that identifies the start of a macro definition block and gets the name attribute so it now uses uses the MSXML DOM, and passes the element object to the code that extracts the body (instead of passing text), now moving the code munging step up to the calling procedure. The resulting code smells better and is significantly smaller.

Note that in the refactoring above, we followed proper TDD procedure, and ran the test suite after each small refactoring step, then fixed any broken tests before proceeding.

Finally, a bit after the lunch break, we had the MSXML calls factored in and were ready to start adding more tests. Now, our earlier refactoring was yielding clear dividends. It was really easy to add new test input and expected output data to the table, the tests were easier to read, and the XML library is handling the majority of our parsing tasks for us, so new tests are made to pass rapidly and without much hassle. We also feel we can fearlessly write somewhat fewer tests with this configuration than we would have otherwise, since we are not having to implement new parsing capabilities ourselves as we go, and can, for the most part, rely on the XML library to behave according to spec. (but not always - we found we had to set .preserveWhiteSpace = True to get the supposedly standard DOM behavior for handling leading white space in text content).

Wrap-up and looking forward:

That's about as far as we got by the end of the day. In story count terms, it's pretty pathetic looking, but both Sam and I felt very positive about what was accomplished. We finished items 2 and 3 from story II, and got most of the way done with Story III that had been in progress the previous week, but still did not finish it. That gives us an official velocity for the day of about 1 story, and an average so far of 1.5 stories per week. Still, we felt that much of today was spent doing essential and meaningful improvement of our process. We also felt that our sustainable velocity was higher at the end of the day than it was at the start, and both our internal code and our metacode language specification smells much better. Steve believes we can safely plan on a velocity of 2 stories for next week.

Due to the fact that we've had a velocity at or below 2 so far and ended up with one or more partially incomplete stories at the end of each session, I think we have to consider whether an adjustment needs to be made to our tracking system. We might have to add a point system, split some of the biggest stories, or something like that. We should discuss that in our planning meeting next week.

New Blog

So I've started this blog to serve as:

• a central point for discussion between team members, and
• a place to record progress made (and/or issues raised) in each session.

Here's hoping it'll be useful...