Disposable Analysis

(This pattern is a dual to MercenaryAnalyst.)

Context: You have a series of artifacts, one (or more) inspired from one (or more) other. (Example: Xp programmers often write CrcCards before they write code.) It's well nigh impossible to keep the artifacts in sync.

Therefore:

Don't try. The early artifacts are guides to creating later artifacts. The later artifacts stand on their own (e.g., TheSourceCodeIsTheDesign). Build your early artifacts to throw away (or to archive for historical interest).

It's likely what you'll do anyway. You might as well plan to. --PaulChisholm

Actually we rarely actually write the CRC cards. Sometimes when we're feeling dull we'll write the class names on them. I can't remember the last time we wrote a responsibility or collaborator on a card.

As we use them, CRC cards are inherently ephemeral. The only residue is what's in your mind when you get up from the table. The cards are often still blank, ready to be used for the next session. So we don't throw them away because we can't keep them in sync - we don't throw them away because they don't record anything.

If you're feeling insecure, you can carry the cards back to your desk while you and your partner type the stuff in. There's one of the team members who actually carries the blank ones back, in case he forgets the design ... --RonJeffries

Ive done something before in Java where I employed LocalityOfReferenceDocumentation by putting my use-cases and CRC cards in the code itself. I added a few of my own "@keywords" to the comments, along with the javadoc comments, for things like @responsibility and @collaborators; and @usecase, @precond, @postcond, and @step. A simple perl script generated the CRC cards and use-cases in HTML format.

It worked swell for me, in that it was trivial to keep the code "in sync", since each @comment was immediately before the relevant line of code. However, even though it was easy to keep things "in sync", the "in sync" effort was still necessary. There's a big difference between making something trivial, and making it completely unnecessary. In my case, I was actually required to deliver the finished CRC cards and use cases with the finished code. But I dont think this is very common.

In most other cases, Id prefer what Paul suggests. If artifacts like "CRC cards" or use-cases are needed at the early stages, but not used later on, I have no qualms about "evolving" them into the code in some format (any combination of code plus comments). Im not as concerned with reproducing these artifacts in their earlier format if I have them captured using sound version control.

-- BradAppleton