Part of my Agile Requirements series.

Fit, Ward Cunningham's tool for agile requirements, is a brilliant tool for enabling discussion about software. As I've listened to people talk about Fit, I've realized that I have an unusual view on how Fit enables this discussion. I'd like to take a moment of your time to explain my vision.

More than anything else, Fit facilitates thinking about the domain. In the same way that test-driven development, when done well, facilitates thinking about design, Fit done well facilitates thinking about the domain. This thinking happens at the requirements level and at the design level. Done right, Fit fades into the background. Let me tell a story.

I'm doing some Fit consulting for a company that builds financial software. The first part of the consulting involved some introductory training. In this three-day course, we spent only a fraction of the time talking about Fit.

What did we talk about instead? We talked a lot about the process that Fit is embedded within. We talked about the prominence of customers over testers in driving the creation of Fit tests--and talked a lot about the high-impact things testers do instead. We talked about the appropriate time to do planning, and how much planning to do when. We talked about Whole Value and Ubiquitous Language. More about all of these in a moment.

We also spent a lot of time doing hands-on exercises within their domain. The story I'm going to tell is about these exercises. Look carefully: you'll notice that the amount of time we spend doing stuff with Fit is almost ridiculously small.

If you've read my Fit Workflow tutorial, the first half of my story will sound familiar. Stick with it. The second half will be entirely new.

We started by picking a story from the iteration plan. Our product manager--I'll call him "Al," because it starts with "A"--stood before a whiteboard and explained why the story was important to our customers and why it had been selected for this iteration.

Next, Al put on his "domain expert" hat. He explained the complicated financial rules surrounding the story. It was one of the fundamental stories for the application, so the financial rules were fundamental as well. People asked questions and Al quickly started providing examples.

We spent an hour or two on this. Note that we haven't done any work with Fit yet, or even with MS Word. Although the examples were formatted roughly in the form of a table, I asked the group not to worry about Fit structure. As a result, we took some shortcuts that made discussion easier.

A couple of key points here: although we haven't used Fit yet, Fit has had a profound impact on the way these folks work. We were spending a lot of time talking about basic domain concepts in a way they had never done before. Al told me later, "I'm surprised that these developers, who have worked here for years, didn't understand these fundamental concepts." Fit facilitates thinking about the domain. Done right, it fades into the background.

After we had a basic set of examples, we stopped and switched over to formalizing the examples in a document. Normally, this probably would involve just a few people, but for the purposes of the exercise, it made sense to do it as a group.

I fired up MS Word and projected it on the wall. As the group dictated, I copied the examples into a table. At this point, we also converted the examples into a style that would work with Fit--a ColumnFixture in this case--although we didn't include the little programming notations Fit requires.

One of the things we were careful to do at this point was to keep all of Al's notations. In fact, we added some back in. One of the columns discussed "movements:" the way money should move around in response to a domain rule. Al had written "ret $200, del $250" in one example. We kept that exact terminology in the Word table.

As a matter of fact, that example started an interesting discussion between Al and our other domain expert. (I'll call him Bo 'cause it starts with "B.") The group wanted to know what "$250 del" meant. Bo said, "It's 'deliver to counterparty.' There's also 'deliver to principal.'" Al disagreed. "I don't call it 'deliver to principal;' I call it 'receive.'" It turned out that the industry had a third term: it calls these kinds of movements a "call."

As a result of this conversation, we made another table that showed the different terms people used and how they aligned. These kinds of conversations are a natural by-product of working with Fit. Although we still hadn't used Fit at all, the detailed thinking it required of us caused all sorts of new information to come out. Fit facilitates thinking about the domain.

The next day, I worked with the programmers. We made Fit run for the first time. We got a basic fixture working and fixed all of the errors. Very quickly, we found ourselves out of stuff to do. We had a few methods and maybe five variables, and that was everything we needed. The methods were stubbed out at this point.

Most of the group was learning this material for the first time, so it took us a while, but the total amount of Fit work was probably five to ten minutes, and that's being pessimistic. Very quickly, we found ourselves having to move away from Fit again. Done right, Fit fades into the background.

In order to make our fixture work, we had made all of the variables and methods strings. That wasn't going to work for our calculations. We could have made the variables just use an 'int' or 'double' data type, but customer had written the values with a dollar sign and we wanted to respect that decision. Besides, our rule was that we had to create types that matched the concepts our domain expert used. (In this case, we thought it was currency.) This is the Whole Value pattern and it's an important part of Ubiquitous Language.

Ubiquitous language was important to us. If there was any misunderstanding between customers and developers, the software would have a bug--possibly a serious one costing somebody millions of dollars. Ubiquitous language allows us to use the same language in our software that our domain experts use in conversation, eliminating an error-prone translation step between our expert's language and the programmer's language. Whole Value is Ubiquitous Language applied to data types.

C#, the language we were using, doesn't have a built-in currency type, so we had to build our own. We switched to test-driven development and did so. As with the domain discussion, the amount of time we spent away from Fit, building this Currency class, was much greater than the amount of time we spent building our 10-line Fit fixture. Done right, Fit fades into the background.

The most interesting thing about this exercise is what happened once the programmers started working their way through the first complete example. The domain logic required looking at the a dollar amount (which could be negative), taking the absolute value and subtracting another dollar amount, then performing another sum if it exceeded a limit, and finally reapplying the original sign.

As the programmers worked on this, they found that they had to implement all sorts of methods on Currency that just didn't make sense for the concept of Currency. Ideas like "absolute value," "multiply," and "divide."

To work our way through this quandary, we started asking questions about what the columns in the Fit table represented. Does it really make sense for a Currency to be negative? "No," the answer came back. Then what in this column with a negative number, what do we have? We struggled with it for a while, and then the answer came. "It's not a Currency, it's a Position. It doesn't have a positive or negative value; it's either 'in the money' or 'out of the money.'"

With that answer, a number of ideas fell into place. Everybody breathed "aha," and we quickly started implementing this new concept. We expect it to be a big design improvement.

Fit was a very small part of the work these folks did. If you count the pieces that were really Fit-specific, it was probably less than half an hour. (A few minutes of copying examples into tables, a few more to add Fit-specific headers to tables, and maybe ten minutes to write the fixture.)

But because they were using Fit, they had to have a discussion about their domain and provide detailed examples. In just one day of hands-on work, the group learned significant new things about their requirements and design. The programmers and testers learned brand-new things about a basic concept. The domain experts discovered they weren't 100% on the same page. The programmers discovered an entirely new domain object that had a significant impact on their design. All this from one day of work.

Fit facilitates thinking about the domain. It triggers new ideas about the requirements and the design. Done right, it fades into the background... but its impact is significant, deep, and lasting.