Remember CRC Cards?
Posted by josh June 14, 2006 @ 12:14 AM
In 1988, Ward Cunningham (yes, that Ward Cunningham) came up with an idea to use index cards as a tool for object-oriented design. I was working for Kent Beck at Apple at the time, so I got to hear Ward describe his idea over speakerphone in Kent's office. Ward and Kent presented a paper on CRC cards at the OOPSLA conference the next year, and suddenly they were all the rage. Some companies even printed up branded CRC cards, which still makes me laugh.
Take an index card. (3x5 or 4x6 are good sizes, but any larger than that and they become too unwieldy to move around.) Write the name of a class across the top. Draw a vertical line separating the rest of the card into uneven halves - the left half should take up about 2/3 of the width. On the left side write the responsibilities of the class. On the right side write the objects or classes of objects that objects of this class collaborate with. That's the basics right there. Once you have cards representing several classes, you can arrange the cards to explore object interactions and discover new responsibilities and collaborations.
While CRC cards can be used solo, where they really shine are during collaborative design. It's easy for one person to move a card around to show others what they mean. Since cards move independently, two people can be writing on different cards at the same time. It makes for a lightweight yet effective group design process. It's also a decent way to describe a design.
CRC cards also play well with the Rails mindset where constraints are empowering. Cards are small, so you can't write so much on them that they become too complex to understand. Limited space keeps you focused on the important stuff. And since cards are easy to make, they are also easy to throw away - no investment equals no pain. Don't like what's on a card? Just tear it up and start over.
A good way to start with CRC cards is to use them to document an existing design. That way you don't have to deal with creating a design while learning a new tool at the same time. Then you might use them to modify or expand the design for existing software. Once you are warmed up with them you can take them for a spin on a brand new design.
My brief explanation hardly does the topic justice. Read Ward and Kent's paper, explore the original wiki for CRC card articles, and of course google around for yet more information.
We used CRC cards to get started on our first rails project and found them very useful. We used a card per controller to get an understanding of the required responsibilities of each controller and at what times one controller would delegate responsibility to another.
I love note cards, for both Design/CRC work and for gathering requirements. I usually have a bunch laying around my desk somewhere. There’s a essence about the physical cards that is hard to capture in a software version of the same.
1988? How old is this josh guy? I thought all the Rails developers were young twenty-somethings! ;P
Yes, CRC cards are one of the most useful design tools, that’s because they’re the simplest… And they make the discussion about the design between different specialists much easier.
Josh’s real age is hard to determine because he sleeps in a vat of formaldehyde, keeping his body in pristine condition.
He looks no older than 27, but don’t be fooled!
Crazy, who is still coming from a procedural mindset these days :) Actually I suppose if you start from the web designer side then maybe it is a new concept.
We use CRC heavily during XP/Agile development(what some youngsters like to call “Getting Real”) and they really shine even when talking to non-developer types, such as when you need to explain a client/server architecture and all the things going on.
I know this is obvious but just to be safe, CRC cards are great for any type of object-oriented development, regardless if you’re doing it in Rails, Delphi, .NET, SmallTalk, JavaScript, etc.
Great post. I used cards to design Docent (now SumTotal Systems). Seems like nowadays I just can’t think about a problem clearly without a set of blank cards. Thanks for that great reminder.
Nancy Craighill’s book, “OpenStep for Enterprises” uses CRC cards as the domain problem for the design and programming exercises. Although perhaps a bit dated (vis a vis its client-server bent), the book is an excellent, short treatment on software design. It’s been sitting on my desk for years—I picked it up and devoured it probably about 5 years ago or so, but I think in homage to this post, I should perhaps thumb through it once more.
I’ve recently taught a two day Rails workshop, and was startled to find out that no one in attendance could tell me what are the three fundamental characteristics of objects.
Re CRC cards, you’ve skipped what I think is the most crucial part—how do we come up with classes (one class per card)?
I like to use problem narrative. Come up with several succinct sentences describing the problem you’re trying to solve. Once you’re happy with the narrative, circle all the nouns and underline all the verbs.
The nouns will be your candidates for classes, and the verbs would be the candidates for responsibilities.
Of course, not all nouns will necessarily end up deserving a card.
ONLY IF SIMPLICITY DOES NOT HURT YOUR EARS, READ ON.
I was part of a XP project in San Diego around 2000 using CRC cards in a novel way. Once classes were realized, we used CRC cards in collaborative design meetings. Each developer and customer representative had one or more CRC cards. A lead developer would start off the interactions between classes(developers and reps). As this interaction evolved each developer or rep would write on his/her CRC cards the services(methods) his/her classes were requested. As this evolved humor was added and it became a very lively learning event. At the end the CRC cards scoped the classes design and everyone attending knew the entire system. This beat writing and reading 300+ pages of product specs. Also the customer knew and believed in the system design which eased the project funding.