by request excerpted from report...
Humans and Technology AlistairCockburn HaT TR96.01 (96.01.31)
While writing this report, I discovered CRC are so effective because they work from examples and are tangible, with fast feedback and let people make and recover from mistakes. That is a lot of goodness in one place. Here are some excerpts...
People work in certain ways better than others
People work better by altering, by working from examples, and working from tangibles. There are counterexamples to these, and they are picked up in the section on Approach Diversity. People often get their best productivity by copying an existing snippet of design and changing it to meet their current needs. Why does this work so well?
"The world carries its own structure, so that specificity always implies generality (and in this sense, generality is not to be assimilated to abstractness). That is why stories can be so powerful in conveying ideas, often more so than an articulation of the idea itself"1. The copied snippet provides both the structure and a sample use of it. The developer can choose to learn the structure, or not. They can get away with just changing the parts that are different. In some cases, a person will change all of the sample, using just the provided structure and the memory of the example.
This copy-modify technique is applied by people everywhere. Cooks copy a recipe and vary just one part. A project manager takes over the previous project's plan and changes every line to reflect the current project. A requirements document or database schema gets copied and altered. An experienced programmer copies her child's hyperlinked program or document to complete a small project without having to learn the nuances of the new medium. In short,
(P9) Provide something to alter.
Copy-modify is currently being applied even to completed applications. There is a growing trade between competitors in non-critical applications delivered with both generated, tuned code and the high-level description of it. These are referred to as "application frameworks". The accepted assumption is that the application framework is not quite correct for the buyer, but will take less effort to fix than it would to build from scratch. An example of non-competitive application frameworks suitable for trading traded is a frequent-flier awards system for an airline company. Application frameworks are quite a different notion than providing a "tailorable" system.
People constantly request examples. It is as though they operate internally and directly from the examples. There is some evidence from cognitive psychology that that may be so2 and there are research projects associated with that idea3. Whether it is actually true that people work directly from examples, it certainly is clear that most people work better given examples than simply working from abstract theory. So it is not only true in expository writing, but in technical development,
(P10) Provide examples.
The modern style of eliciting application requirements is example-based. We find that people give better requirements when given specific situations to discuss and walk through than when just asked for their input. Even better than discussing the future system is to enact the use of the new system, making an actual performance of it. The performance is both example-based (P10) and tangible (P11). Some organizations create fictitious employees having different personalities. The users describe how these made-up employees would get their work done. A lazy employee might find ways to defer work until later, while an ambitious employee might find ways to get the most accomplished soonest.
Example- and instance-based design techniques are well received by designers. Where a few, talented individuals can handle the powerful, abstract techniques, the masses of developers have trouble with them. It is not a matter of teaching. Abstract techniques will always attract fewer practitioners, however powerful it might be.
Better than working from an example is working with something tangible. The tangible item is both an example, and it plays into our senses.
(P11) Provide something tangible, where possible.
An example of working from tangibles is the "CRC" (class-responsibility-collaborator) card exercise4. Index cards represent components of the software system under design. The designers write on each card the component's responsibility to the functioning of the system. They pick up the cards and walk through the operation of the system in particular situations. CRC cards have been transferred onto the computer screen by numerous practitioners, but somehow lose their effect there. There is a particular effect in working through the design that comes from reaching over, pointing to a card, picking it up, and perhaps moving it to the side.
Cognition in Design
A set of design techniques have shown up over the last years which improve the match with the cognitive factors mentioned earlier. In the requirements gathering phase, written "usage scenarios" and role-playing have gained acceptance for discovering more obscure requirements and user needs. In user interface design, there is an entire school of thought devoted to using paper, cardboard, and other tangible prototypes, in addition to usage scenarios. In object-oriented design, the CRC card technique has been found effective by many teams who have tried them. The discomfort to software developers usually is that these techniques involve role-playing, a relatively extroverted activity for a relatively introverted group of people. Each of these techniques also emphasize tangibility in some way. Paper prototyping and CRC cards both seem to lose some of their effectiveness when put onto the computer screen.
Lo-Tech vs Hi-Tech
Low technology includes both paper prototyping and designing with CRC cards. They are clearly effective. However, it is difficult to sell yourself as the most advanced development group in the world, standing in front of an audience and holding pieces of paper; it is easier to do the same standing in front of a computer screen. Thus, the lo-tech vs hi-tech debate is an artifact of the clash between improving technology and recognizing cognitive factors. Just as the formal vs informal debate is not likely to diminish in the near future, neither will the lo-tech vs hi-tech debate.
Given a choice between a cognitively matched method and a hi-tech method, (a) the cognitive method will be generally more effective, (b) the hi-tech method will generally be selected by management, (c) the cognitive method will generally be applied by busy practitioners in the trenches.
excerpted from report...
Humans and Technology Alistair Cockburn HaT TR96.01 (96.01.31)
Alistair is presently moving much of his work to his own site at:
Try more specifically (for CrcCards
His article list