CRC Cards

I (Ward/Eric Dobbs) work the machine as I talk to the stakeholders. You say something is important then I write it down. Some cards stay in front of me because they really are important. Some fall off the table never to be missed.

A small team practices designing with CRC Cards at Agile Open 2006. archive

I turn the crank on the machine. The cards move each turn. Folks watch the machine and correct it when they feel it is wrong. Sometimes they are wrong. We learn either way.

We call this Design because we end up with something that no one individual knew before we started. But there is no new knowledge in the room. It's just more evenly distributed. No different than a cake mixer really.

# Decisions

A huge number of important decisions can be made with a dozen cards on a table. I've done this sort of planning with international executives planning years of work. I'm holding a card, telling a story. I get to a hard part and ask, what happens here? Eyes turn to one guy. He is the decision maker. I pay close attention to everything he says.

YOUTUBE jqGYoKvekik How big decisions are made. Conversation with Ralph Johnson, Ward Cunningham, and Tom Munnecke about refactoring the VistA medical information system.

I worked once with a bunch of recent graduates all trained up on the latest technology. There is one old guy hanging around who refused to participate. Retirement was just months away for him. I'm telling a story guided by one kid. Another kid agrees. The old guy leans forward and says that won't work. What? How do you know the kids ask? Because we tried that in 1972. It didn't work then and it won't work now. You're not thinking this through.

# Machines

The index cards elevated the conversation to where everyone could participate. Everyone understood what was being suggested. They could all imagine doing each role themselves. If they could to it then it could be programmed.

Each card identified a class of objects. On the card we write the responsibilities as verb phrases. It it sounds too hard we identify the collaborators that will help meet a responsibility. We check what is written on their cards.

Class - Responsibility - Collaborator Cards.

These are teaching machines. Little pieces of paper that keep our short-term memory synchronized while we talk through the big problems that our future system will face.

# Personification

This works because we can imagine being the objects in a program so long as we don't have to remember more than is written on an index card.

Some observe that the card stands for all X objects in the program until we pick it up. Then we are talking about a specific X, the X that we care about for the moment. We tell the X story without feeling a bit childish. This is serious stuff. Every scenario must be heard through.

After a while you have all the cards you need to tell every story. This might be three cards. It might be thirteen cards. But it won't be the three hundred cards that you wrote before you started thinking through how the program will actually work.

# Cards

A group of people who care about a program meet to discuss how it will be programmed. There will be an X and it must take care of Y. We make a new card. Class X. Responsibility Y.

The CRC Card for Figure, one of a dozen cards for HotDraw among the first programs to be described this way. website

Someone says, what about P and Q? We write another card. But how does P get along with X? We tell the story of how. If X can do Y and P can do Q it sure sounds like it will work. We're ok for the moment.

The cards are like little puppets that are acting out what we think the program will do. When somethine else comes up we write it on the card that will do it.

Sometimes we don't believe an X or P can do Y or Q. Then what? We imagine doing the job ourselves. Who would help? What are they called? What role do they fill? We hypothesize an A that does B. X and Y collaborate with A to get B done. Were ok for another moment.

Object-oriented programming offered an inversion of how to think about programs. It was a little thing with a big difference. How to teach that?

Computer programs before objects followed a thread of control from statement to statement, function to return. It worked. But as programs got bigger the names lot longer and harder to say.

With objects every name was qualified by what object answered to it. The names were about responsibilities that an object could fulfill. You say what to do, not how to do it. Same name meant same thing, not same steps to completion.

People are like that too. You say, lets meet tomorrow and you meet tomorrow. How did that happen? You don't care.

We can practice thinking about objects meeting responsibilities by telling stories about what will get done. We don't say how. We say this or that object will take responsibility and get it done.

.

I think Event Storming and CRC Cards are similar design tools applied at different scales. See Event Storming

The video conversation with Ralph Johnson, Ward Cunningham, and Tom Munnecke is a fascinating discussion about refactoring, different levels of abstraction, and challenges of problem decomposition. Tom and Ward also had a conversation about VistA at Health Camp Oregon: youtube

YOUTUBE pSnCN-HQXvI Wiki inventor Ward Cunningham and VistA architect Tom Munnecke at Health Camp Oregon