On the agile-testing group, there has been a little discussion about offshore testing. Herewith, some thoughts, cleaned up slightly from my comments there.

I was glancing at the delegates version of the code last night, and I have the impression that the frame status requirement will be more readily implemented there. So today we give that a try. The results are strikingly better than yesterday’s!

Today we set out to finish the essentials of the FrameStatus implementation for the Kicker version of the Bowling Game. Things go in easily, without many surprises. But we have a lot of code, and it doesn’t all feel good.

We have a very procedural implementation of the bowling game, and a very nifty OO version with classes representing states of a state machine. Which implementation is more responsive to new requirements? We’ll find out soon!

We use the C# “delegate” feature to come up with a solution to the Bowling problem that is perhaps a bit less OO, but is also only 40 percent the size of the version with the Kicker classes. Fun exercise, but the proof will be in the next stories. [updated, see footnote]

I wrote this answer in response to a question on one of the Yahoo groups: “What is the list of documents produced when you are implementing a pure Agile project?” Martine Devos liked it, so I decided to preserve it here in hopes that someone else might like it as well.

We build some superclasses to remove the duplication from the Kicker classes. One false start sends us down an unpleasant path, and we decide to start over more cleverly. As for the end result, we have our doubts. The proof will be in the updating, later on. Right now, it’s hard to see why five times bigger is better, just because it looks like Object-Oriented.

Chet and I get this version running all the way, by implementing the Strike functionality. We do some cleanup, and plan next steps. We can get a pretty good look at the OO-style version of bowling. Is it better? It’s not clear.