The CRC Card was invented to simulate a style of software development that I had found particularly well suited to object-oriented programming. (See "A Laboratory for Teaching Object-Oriented Thinking" by Beck & Cunningham.) In the years since, I have accumulated considerable experience with CRC, both in the simulated style, using index cards, and in its more natural form, interacting with the computer. This position paper reports that experience, especially as it applies to teams.
CRC stands for Class, Responsibilities and Collaborators. My colleague, Kent Beck and I would struggle to coax a program into existence sitting side-by-side, sharing the controls of a then new Smalltalk workstation. We found repeatedly that our problems would yield when we could articulate the responsibilities of the objects we had made and the collaborations they would use to meet those responsibilities. I had many months experience with such grappling before I ever tried to duplicate the sensation away from a computer. The first ever CRC Cards were written at 4:00 a.m. one morning on my dining room table. The first ever team development of CRC Cards took place around 9:00 a.m. that same day as Brian Wilkerson and I grappled with responsibilities at a cafeteria table 1000 feet from our machines. As with Kent many times before here I was coaxing a program into existence. I'd like to leave CRC for the moment and instead focus on what I mean by coaxing a program into existence.
A program is decisions made. Humans make those decisions and write them into programs. When I compare the research programming I did early on to the production programming I've done recently, I find that the activities differ only in the quantity of decisions made on a given day. In both cases decisions come in spurts. A period of investigation precedes a spurt of decisions. Likewise, a period of rather mechanical activity following through with consequences follows a decision spurt. The feeling one gets is of lifting a problem up into the mind, struggling with it until decisions come, then, putting those decisions down in place of the problem. Only then can one relax. This cycle repeats. It's what I call grappling. I feel it when I program, with cards or at a machine.
I now call these grapple cycles programming episodes. Episodic programming is most noticeable when decisions require judgment. Mechanical decisions, like looking something up in a book, don't feel particularly episodic. But, then, they aren't actually decisions. Designing framework software on the other hand does require judgment and progresses in distinct episodes.
CRC Cards work by taking people through programming episodes together. As cards are written for familiar objects, all participants pick up the same context and ready themselves for decision making. Then, by waving cards and pointing fingers and yelling statements like, "no, this guy should do that," decisions are made. Finally, the group starts to relax as consensus has been reached and the issue becomes simply finding the right words to record a decision as a responsibility on a card.
I've had people tell me about their struggles to make CRC Cards work. Often many none-too-fruitful sessions preceded an almost spiritual experience when the right people are finally assembled and they "come together" to break a log-jam of indecision.
Such reports are of course satisfying. Even more satisfying is my more recent experience in front of the Smalltalk browsers. Having left research, I found myself swimming in a river of decisions. As I pointed out earlier, production programming requires many times more decisions per day than research. Production decisions are rarely as profound as those in research, but they are of equal or greater consequence and demand as much or more judgment. Our production team "came together" when we learned to work through episodes promptly and in synchronization so that our collective experience came to bear on all of our decision making.
We regularly worked two to a machine. This worked best when we had enough framework in place that our Smalltalk code read like specification. An episode would begin by poking around with "senders", "implementers", a few "inspectors" and an occasional "ctrl-c". We were lifting the problem into our collective consciousness. One would type, the other watch, then trade off. As we approached decisions our attention would turn to each other. The communication would become complex as human communication often does. I won't attempt to analyze it except to say that it includes a lot of hand waving, body motion and statements like, "hey, that guy shouldn't do that." Finally, decisions would be made and the consequences followed through, not by writing on cards, but, by adjusting the specification- like code. And, as with cards, we would search for just the right words to represent the decisions as they had come to us.
What I've just described, I'd felt in research. And, I thought of it as just a happy compatibility. In production, our machine sharing collaborations were more intentional, based on our need to work quickly and correctly. It was a practice that grew slowly in our core group of four implementers, individuals of only average compatibility. The practice spread by first-hand experience. First others learned that I preferred collaborative episodes as a work style. Then they chose to work that way too. Ultimately, any possible pairing was likely in the office and a group of three would form when the problems required that much talent.
I'd like to point out again the unusually high capacity human-to-human communication path that is opened by two people sharing a machine. As the developers work through whole programming episodes together, the machine presents a broad range of situations to be dealt with, all, of course, relevant to the work at hand. In order to stay synchronized each programmer must at least follow the problem-solving strategies and techniques of the other. Things that worked were obvious. These spread quickly as did our general understanding of what worked well and what didn't in the program as a whole. In the few cases where programmers chose to disagree, one would occasionally have to admit, "you technique would have really helped just then."
I now recognize the organization we built to be a High-Performance Team. (See The Wisdom of Teams by Katzenbach & Smith.) Such teams are recognized by their ability to play to member's strengths while covering for each other's weaknesses. We were able to work at maximum productivity continuously and indefinitely. When an occasional crises did occur, we simply pulled the most relevant people together and worked through the problem as another episode. We new we were working on the most important thing in the most productive way. No further urgency was necessary.
In summary, Smalltalk's specification-like coding and incremental development environment permits a unique human-human-machine dialogue. CRC Cards allow larger groups to feel this dialogue which is based on repeated episodes of decision making. Finally, members of somewhat larger production development teams can exploit the human-human-machine dialogue on a pair-wise basis. The complex communication that then takes place will support a High-Performance organization with many benefits, a few of which I have mentioned.
See A CRC Description of HotDraw for first ever CRC-Cards.