I got a response from Chris Wheeler about yesterday's blog entry today. Chris has one of the most in-depth Fit installations I know of--his team has been using Fit for a year and a half on a non-trivial project. I was glad to hear that his experience bore out my intuition about Fit and User Interfaces:

Anyway, a quick note about your FIT for UI posting - timely! We here have come to alot of the same conclusions about using FIT for UI testing and spec'ing. As well, I found it very interesting when you wrote about programmer integration tests being cheaper - we have started to move in that direction for some things. In fact, we've built 'bridging' fixtures from FIT to NUnit so that we can use FIT to specify a story, but use cheaper NUnit tests to prove they work. We've done the same with TestPartner (our UI testing tool).

(Chris, I'm sorry I haven't replied to you directly. I can receive email at the hotel but I'm blocked from sending it.)

My favorite session today at the Agile 2005 conference was Tim Lister's evening speech. It was vastly entertaining--by the end of the talk, thanks to members of the audience, Tim was on his third beer--and it contained some great insights as well. (The quotes in the following material are paraphrased.)

The title of the talk was "More Things No One Wants to Talk About." Tim talked about managers ("Managers are lonely. They have no one to work with and they have to take classes about stuff that doesn't matter.") and QA ("Of course QA is a bottleneck! It's meant to be a bottleneck! If developers hand QA crap, their work is going to reflect that!")

But my favorite part was the section on requirements: "Getting Agreement on Requirements is Not Neat." Tim had a particularly vivid commentary on the idea of requirements gathering. He showed a girl picking flowers, with a thought bubble:

"Oh, here's a pretty orange requirement. I'll gather this up and take it back to company headquarters."

The point, of course, is that "requirements" don't just lay around waiting to be picked. You can't gather them. People have to make them up, and that's a messy process that generates a lot of ideas.

(Part of the reason this part of Tim's speech captivated me is that I've been thinking about this stuff a lot lately. You can see some of my other thoughts on the matter in my blog entry "Ideas, Not Requirements" and in my presentation "Beyond Story Cards"--which has become quite popular--as well as yesterday's blog entry.)

Tim made the astute point that when deciding what software to build, you need to understand the problem, not just the solution that customers say they want. This isn't exactly news, but the agile community focuses so much on serving the customer that I think we easily lose track of this important point. I know that I've been guilty of expecting the customer to have all of the answers.

Another good point that Tim made was that no solution will be the right one. The important thing is to listen and and try ideas. I liked his idea that you should never talk to anyone in the community without having something to show "that they can point and laugh at."

Tim had many other entertaining and interesting things to report, but that's what struck me. For the rest, well... you had to be there. :-)