2007-07-29

奖励的惩罚

奖励和惩罚,一个是胡萝卜一个是大棒,应该平级的,奖励是奖励,惩罚是惩罚,怎么会有奖励的惩罚呢?

奖励的惩罚,这是一本书,埃尔菲.艾恩写的,在读这本书之前既不知此人,也不知此书,只是看名字有个性翻看了一眼,继而买下。

书名看起来矛盾,但作者用整本书解释这其实不矛盾。奖励和惩罚不是对立、不同的东西,而仅仅是一个硬币的两面而已,其本质上是相同的,都是一种对他人的控制手段,目的都是控制他人,服务于自己。

随着社会的进步,惩罚的缺点逐渐为人所认识,不管是在学习、工作中,或在家中,都倾向于越来越少用惩罚的激励手段,代之以奖励的诱惑。表面上看,这的确是进步多了,并且人们相信这是很有效的方式,能使生产率、学习成绩等显著提高。

是这样的吗?作者分析了很多原因证明人们错了:

  1. 奖励的惩罚:
    • 奖励和惩罚是一个硬币的正反面,奖励的范式为“做此即得彼”,如果做不到“此”,自然也就得不到“彼”,本来满怀期望得到“彼”的可怜人在做不到“此”时的心情和受到惩罚有什么两样呢。
  2. 奖励会破坏人际关系
    • 奖励者和接受者是一种对立关系,在地位上是不平等的
    • 无视团队作用,破坏团队精神。往往成功是和多种因素、多人贡献分不开的,但往往“一将功成”,难免对没有受到奖励的人是一种打击,进而为以后的合作造成障碍。
    • 如果奖励整个团队呢?也有问题,这时获得奖励的因素不光是自己,还有别人,一则减弱奖励的刺激度,一则会让先进者仇视拖后腿者,造成竞争关系。
    • 由于奖励的数量有限,总会造成你争我夺,难免伤了和气。
  3. 忽视问题的原因
    • 往往是出了问题,才会使用奖励的手段来解决。例如正是因为员工缺乏内在工作激情,才会有奖励来作为外在激励。正是由于学生对学校教育不感兴趣,才需要用分数刺激学习。
    • 奖励只是为了控制人们去做奖励者想要他们做的事情,目的达到就兑现奖励,并且往往会作为一种制度延续下去。于是皆大欢喜。
    • 本应该对问题进行深入分析,找出背后原因,可是被奖励解决了问题的表面现象蒙蔽之后,人们止步于此,真正的原因无人深究。人们为什么不努力工作?学生为什么不好好学习?
    • 这可以认为是一种黑盒控制,而非白盒控制。
  4. 奖励阻止冒险
    • 得到奖励的承诺后,人们会为奖励而努力,原先的完成任务的目标被得到奖励的目标所代替。正是:奖励激励人们得到奖励
    • 紧盯着奖励,关注点更狭窄,对于和目前从事的活动无关的事情不去关注。只做为得到奖励所必须做的事。
    • 对回报考虑的越多,越要寻求确定性。这自然是探索的敌人。
    • 当心中想着“挣取”奖励,自然会考虑“产出/投入”比,产出一定的情况下投入越小越好,因此会选择简单的任务,避免挑战,不追求高质量,敷衍了事。所有这一切都是为了节省投入。
    • 由于奖励激励人们得到奖励,停止奖励,自然之前受奖励者会停止受奖励的行为。
  5. 奖励改变人们对他们所做之事的感觉方式
    • 外在奖励减少内在动力。“大家都是聪明人,你为了让我做这件事而奖励我,肯定这件事不值得做,才会补偿我……”,这种想法很自然。本来已有的内在动力却被奖励给破坏了。
    • 使人感到受控。没有自主权的情况下往往畏缩不前。在有选择时,就可能不会继续做下去,即使胡萝卜依然存在。依赖外部动力,以至于最后一刻才做。
    • 当人们内在动力不足的时候是不是就顺理成章地使用奖励的手段呢?当然不是,内在动力不足是有原因的,得找出这个背后原因,并且解决之。并且应该给人们更多关于如何完成这个任务的自主权。
    • 内在动力可以持久。而奖励停止就使受奖励者停止奖励的行为。来可以持续的行为被扼杀了。

其实还有一个重要的问题作者没有强调,以上的声讨还都基于奖励者可以准确、公正地判断是否达到奖励的标准的假设,这是奖励得以执行的前提。这个假设太乐观了。很多情况下这个前提就不成立,更甭说后面的奖励是否有问题了。考试成绩作为检验学习效果的办法,这是一种不得以的办法,因为目前还没有能直接测成绩的公正仪器。在公司的环境里,决定对员工的奖励的是员工绩效,这个绩效的评估比起考试,其客观公正性又差了很多。在感觉到不公正地待遇之后,很少有人能做到一如既往地工作。很遗憾的是,这是一个普遍性的问题。

既然奖励的惩罚如此严重,该怎么办呢?

作者开的药方就是用人的内在动力替换外在动力,而非相反。具体如下:

创造特定的条件,使人们对自己做的事情的兴趣最大化,同时,消除那些对人们的兴趣起反作用的条件和因素,例如放弃奖励。这些特定的条件是什么呢?基本的有三条(3C):

  1. 协作
    • 术业有专攻,人的才能特长是不同的,但往往完成任务需要多种才能,这时候的协作交换就很重要了,包括才能和资源的交换。这样是一个共赢的环境。
    • 人不是机器,是有感情的,即使是在工作中也一样。协作给人们以社会性支持所带来的情感支撑。
  2. 内容
    • 人们没有动力去完成任务,往往是因为任务本身不吸引人。改变工作设计使其乏味与繁冗程度降到最低。
    • 人需要被重视的感觉,因此如果任务不重要,就不能吸引眼球,也就没有动力去做。需要让人感觉到任务的重要性。
    • 在可预期与新奇性间找到平衡。对于明确知道结果的任务很少有动力去做。对于挑战太大的任务也很少有人敢/愿意去做。
  3. 选择
    • 人们不希望被别人操控,希望自己掌控自己,因此尽量让人自主决定采用何种方式达到目标。
    • 参与式管理。在工作场所推行民主。

我是读完了这本书,但不希望那些能决定年终奖金的人读这本书。因为这些人往往很忙,看书基本扫一眼,很大可能会“碰巧”扫上“放弃奖励”这几个字,立马大呼“正合孤意”,立即着手取消年终奖……这倒不能怨作者,作者其实在某个地方强调了:取消奖励的同时需要慷慨而公平地支付报酬,尽量确保不要让人们感觉被剥削,尽你所能帮助人们忘记金钱。这点是非常重要的,在整天考虑房贷如何还,晚饭的米还没有着落的时候,人们是没有办法安心工作的。并且,年终奖可以不取消的另一个原因是它并不是那种老板在年初挥舞着一个任务列表向某人宣布“如果能完成这些,年终就有×××奖金”模式的奖励,而是一种公司对员工的分红。

2007-07-23

北京计算机从业人员关键词排行表

Something interesting from 春江润楠 北京计算机从业人员关键词排行表. It shows something:

 

I collected all the following records by seraching jobs in Beijing from www.kooxoo.com in July 22-23, 2007.
Notice that:
    1) The number behind the keyword is the number of the jobs retrieved.
    2) The keyword list is in desceding order by comparing the number of jobs retrieved
    3) The keywords are just the 96 words which flied into my mind randomly

Ranked Keywords List used in Jobs Requirements for CS People in Beijing
-----------------------------------------------------------------------

软件 174879
English 91113
软件开发 59598
沟通能力 36961
协调能力 19626
软件测试 14102
数据分析 13233
团队精神 10509
Java  9887
互联网 5782
c++ 4056
.Net 3516
Linux 3027
Excel 2975
日语 2589
Photoshop 2449
flash 2388
Oracle 2385
windows  2156
SQL 2155
Word 2071
J2EE 2057
Unix 1643
php  1627
AutoCAD 1553
C 1451
asp 917
游戏开发 807
SQL Server 740
jsp 723
MySQL 672
XML 642
游戏设计 631
DreamWeaver 585
职业道德 538
HTML 517
Eclipse 435
3DMAX 433
有责任心 412
UML 399
游戏策划 399
DSP 369
Delphi 355
FPGA 347
搜索引擎 312
TCP/IP 296
上进 294
Hibernate 287
struts 260
AJAX 252
数据挖掘 245
ARM 232
Servlet 215
Spring 207
MFC 197
SPSS 191
EJB 178
Socket 172
perl 137
Weblogic 137
Lotus 131
Sybase 126
Tomcat 126
WebSphere 119
SAS 115
Apache 104
FreeHand 87
自学能力 86
信息检索 55
Visual C 51
Power Point  51
DirectX 48
verilog 46
STL 46
Informix 45
OPENGL 41
matlab 39
Rational ROSE 36
Java Script  34
HTTP协议 31
信息提取 28
lucene 27
自然语言 27
cgi  26
python 24
resin 18
spider 16
foxpro 13
ruby 12
Visual Basic 12
SMTP 9
JSTL 7
Fortran 6
分词 5
文本挖掘 4
语料库 3

2007-07-22

房价上涨剥夺白领阶层再发展能力

刚浏览过一个网页,专家称房价上涨剥夺白领阶层再发展能力:

“真正的穷人,不要说房价在1万元/平方米,降到6000元/平方米、2000元/平方米也买不起。更高收入的人,则不在乎房价是1万元/平方米或者1.8万元/平方米。”这样情况下,房价伤害的是特定一群人。这些人是整个社会发展的中坚,处在创造最大价值的年龄段。但同时他们上有4位老人,下有一个小孩,所有的担子压在他们的身上。而房价的上升,让他们把以后几十年打工的收入都要拿出来买房。这些收入本来可以用做他们自己再教育,或者读一个新的学位,或者投资,或者参与小型的企业创业。“房价透支的不仅仅是钱,而是透支这些人不断往上发展的路径,对这些人的发展权是一种明目张胆的伤害。”

还是挺有道理的,财富集中于政府或一小部分人手里对于国家的长期繁荣昌盛绝不是好事,有希望的社会应该是藏富于民,即使不是全民,至少得有一个适当比例的中产阶级,社会阶级分层应该是一个椭圆形的结构,而非金字塔形结构。当这个中间阶层由于房子而降为房奴的时候,政府上从每个“奴隶”身上获得的仅仅是可怜的个人所得税,而失去了很多这些人本来应该能做出的更多的社会收益。奴隶可以成为将军,但其机会远远小于非奴隶成为将军的机会。

当然,房子终究不是空气,可以无偿拥有,总会有人的再发展能力被剥夺,白领阶层的夺不得,蓝领的就能夺?这是一个公平的问题,虽然社会从来就不是公平的。

政府能做些什么呢?

如果说房价是市场行为的结果,政府无能为力,那么市场不规范是否是政府的责任呢?即使规范市场,打击炒房也无能为力,是否能做些其他的呢?

房价高,有人买,这是需求的问题。这需求从何而来呢?自然是人,大家都集中到一起,房子作为资源自然就会配置到能出最高价的人手里。

大家为什么都集中到一起呢?因为这些地方比其他地方好,经济发达,挣钱容易。如果其他地方也发展起来了,就没有必要非挤到一起。前几年的“西部大开发”怎样了?好像没啥消息了。政府到哪儿去了?

即使是同一个城市,不同区域的房价也不同。为什么?还是发展的机会不同,设施不同,条件不同导致很多公司集中于某些区域,大家也竞标这些区域的房子。甚至很多人为了孩子而竞争好学校周围的房子。这也是机会不同造成的。政府为什么不努力把机会均匀化呢?政府到哪儿去了?

有信心长久统治的政权是不会有杀鸡取卵的行为的,其行为会考虑长久投资回报……

2007-07-20

鱼与熊掌不可兼得?

鱼与熊掌不可兼得。

真的?为什么不可兼得?在这句话出现的时候还没有动物保护法,鱼与熊掌兼得没啥难的,不就是钱嘛!(每样两份,吃一份,打包一份!!!)

宽与严不可兼得?学程不识就得贬低李广?大可不必。

是此非彼?非此即彼?这种思维是机械的0/1逻辑,计算机中可以这么简单,但现实世界可不能如此简单。在同一个人身上优缺点总是共存的。因此,两个人身上都有优点。既然如此,何必扬程抑李?!

程不识正部曲、行、伍、营陈,击刁斗,士吏治军簿至明

这是程不识的优点:管理上很规范,井井有条。

士卒亦佚乐,咸乐为之死

这是李广的优点:对激励士卒很有一套,很人性化的管理。

二者结合起来怎样呢?管理很规范而又不失人性化。在工作流程上很规范,在团队建造方面不失人性化。在管理体系构建和团队凝聚力构建上两手抓,两手都要硬。

简单说也就是:让人知道要做什么,如何做,同时还要给人愿意主动做的理由。

说起来简单,做起来不简单!其中有一些是相互矛盾的,需要平衡,绝不是技术可以做得好的,需要艺术。

鱼与熊掌,兼得是挺美。可这需要有钱 :(

鱼与熊掌,是否需要兼得?

干嘛那么奢侈,有嘛吃嘛,不是任何时候都要鱼和熊掌的。年纪轻轻,身体倍儿棒,只有鱼的生活也不错嘛!

如果是简单工作,能很容易衡量生产率,用计件等方式就能很好产生外部激励,很难有人性化管理的动力。虽然从人道上说有人性化必要,可是从经济上说是没有必要的。

软件开发呢?太让老板们失望了,这是需要创造力的工作,是那些能“心在曹营身在汉”的地方,不人性不行啊。得大补!

2007-07-16

Joel论管理

李广和程不识二者的比较对我们有何借鉴呢?对软件工程管理(领导)有何借鉴呢?

在大洋彼岸的Joel估计是没有机会来从《资治通鉴》吸取营养了,不懂汉语可不能怨别人,但却不影响其对此问题的思考和得出的结论。在其Three Management Methods系列中,对三种类型的管理的见解很有见地,值得看过以后回味发散一番:

The Command and Control Management Method:此方法即来自军队的管理方法,其基本思想就是人们做你告诉他们做的事,如果他们不听,就向他们吼叫,如果还不听就惩罚,直到去做为止。Joel认为此方法对高科技团队无效:

  1. 人们不喜欢被命令。尤其是自认比其他任何人都聪明的程序员们。
  2. 管理者没有精力对每个人实行微观管理,因为每个人做的事情都不同,不像在军队,一个命令对大家都管用。因为没有精力对每个人工作有那么详细的了解,不可能对每个人下正确的命令,只有执行者自己掌握的信息才是最准确的。
  3. 公司不同于军队的地方是职员在感觉不爽的时候可以辞职,有选择的自由。越是优秀的职员可选择的机会越多。

军队用这种方法也不是因为士兵喜欢这样,而是只有这种方法可以让人迎着枪林弹雨冲锋陷阵。士兵逃跑有军事法庭处理,而员工辞职受法律保护。

The Econ 101 Management Method:Econ 101是多数美国大学里的一门面向非经济学专业学生的基本经济学课程。放在这里当然是讽刺那些对经济学一知半解,但却热衷在管理中使用经济激励的管理者。这些管理者认为所有人都被钱所驱动着,因此让人做事的最有效方法就是物质奖励和物质惩罚。同样,Joel认为不可行:

  1. 用外在激励代替了内在激励。本来人们有做好事情的内在自然欲望,当管理者无视这些内在驱动力,而用外在的物质奖励驱动时,人们会受Overjustification Effect影响,美好的自我实现欲望被引导为物质追求,内在驱动力被埋没。而外在激励在强度上要远弱于内在激励,因此,奖励反而起到相反的作用。(这也就是所谓的《奖励的惩罚》)
  2. 这种方法会刺激人们寻找最大化收益的方法。奖励总会有个标准,比如多少行代码多少钱,如此,大家都会努力多写代码,而不是努力开发高质量的软件,更不是努力开发能赢利更多的软件。(道高一尺,魔高一丈
  3. 这种管理方法的最大问题是它更本就不是管理,管理者拒绝思考和培训员工如何让事情做得更好,只是用金钱引诱大家做事,用各自的方法去做。

管理者很重要的职责是创造一个系统,包括各种工作流程等,在其中大家能把事情做好。在系统中,大家可以在基本原则指导下充分发挥主动性完成工作。

The Identity Management Method:努力使团队向一个方向努力,这个方向指向管理者想达到的目标。和Econ 101方法相反,Identity方法激发团队成员的内在驱动力,让所有人和组织保持一致和认同。

  1. 整个团队有共同的愿景,是一个整体,像一个联系紧密的家庭。大家在一起相互信任和忠诚。
  2. 为了保持一个方向,要和成员共享必要的信息,让大家有足够的信息做决定,而非命令。

Joel当然是支持Identity方法的,因为这就是他管理自己公司的方法。

从Joel对上述三种管理方法的分析来看,虽然没有读过李广和程不识的故事,却好像专门总结了二者的治军方法。The Command and Control Management Method就是程不识的治军方法,而The Identity Management Method对应李广的治军方法,所谓:

得赏赐辄分其麾下,饮食与士共之。

广之将兵,乏绝之处,见水,士卒不尽饮,广不近水,士卒不尽食,广不尝食。宽缓不苛,士以此爱乐为用。

2007-07-15

激励

李广和程不识在管理上,一宽一严,都成功了。士兵爱戴李广,愿意随之出生入死,而司马光却告诫后人不用随便学李广,除了说李广是学不来的,后继者无法继续外,还说:

夫小人之情,乐于安肆而昧于近祸,彼既以程不识为烦扰而乐于从广,且将仇其上而不服

至此,司马光这个老封建的反动本性显露出来了,诬蔑我们“人民子弟兵”好逸恶劳,还试图扼杀李广式的爱兵如子的将军,以免大家有逃离大棒,转投胡萝卜的想法。这事放到现在判一个反人道主义罪或反人类罪应该没啥问题!

当然,对于一个千年以前的人愤怒是毫无意义的,心平气和地分析才是更重要的。

李广真的不能学吗?其实不是不能学,而是一般人学不会。李广“行无部伍、行陈,就善水草舍止,人人自便,不击刁斗以自卫,莫府省约文书”,以至“咸乐为之死”,这对一般人来说太高深了,对士兵实行的是内在激励方式,使士兵自己主动卖命,而不是需要后面跟着一个端着刺刀逼迫才前进的。这当然不是例行公事的领导所能做到的,因此才说后继的很可能就做不到。

程不识呢?和李广相反,“正部曲、行、伍、营陈,击刁斗,士吏治军簿至明,军不得休息”,靠的是严酷和纪律,但“士卒亦多乐从李广而苦程不识”,典型的外激励方式。这种方式需要做到严格执行,例行公事即可。

这两种方法的境界有高低,但效果很难说哪个更好,得看环境。抛去阶级感情来看,对于军队来说,司马光分析的还是很有道理的。军队里工作方式是要真正拼命的,要使内在驱动力达到能使人拼命的程度,激励的成本是很高的,相较之下,由国家机器在背后支持下的大棒式外在激励却成本低廉,对于全国大规模推广具有可行性。

2007-07-13

和平演习

冯唐易老,看来俺也老了,上周轻微的气温波动就带来了一场不大不小的感冒 :(

也可能是刚又看了一遍《系统思维导论》的缘故,潜意识里对免疫系统很久没有大规模实战感到担忧,于是发动一场实战演习。从回复的速度上来看,效果还是蛮好的 :)

同时也提醒:对“储备”的透支需要及时补上……

2007-07-08

冯唐易老,李广难封

嗟乎!
时运不济,命运多舛。
冯唐易老,李广难封。

这是《滕王阁序》中作者在暗怨自己生不逢时,怀才不遇,用古人的事例宽慰自己。看来这怀才不遇的抱怨是由来已久,因“时运不济,命运多舛”而郁闷的人何止一人哉!

冯唐就不说了,除了为人耿直直言之外好像也没有太多的英雄色彩。但飞将军李广就不一样了,从小学课本的“但使龙城飞将在,不叫胡马度阴山”、“林暗草惊风,将军夜引弓。平明寻白羽,没在石棱中”等诗句就开始知道并崇拜这位名将。高中时读《史记》,看到司马迁记载的李广传,更深入了解其一生的传奇经历,更认同《滕王阁序》中的感叹:时运不济,命途多舛。如此勇猛的战将,一生对匈奴七十余战,却终生没有获取封侯的荣誉,最终落得个自杀的下场,不禁让人扼腕叹息,为其鸣不平。

最近在读《资治通鉴》的时候,再次读到关于飞将军的记载,和史记中的记载类似,只是按年代将其他人同时发生的事穿插记载,更有时间及背景关联。又感叹了一番。

其实,在《史记》和《资治通鉴》中对李广治军和才能描述中都有和另一位将军程不识的比较:

广行无部伍、行陈,就善水草舍止,人人自便,不击刁斗以自卫,莫府省约文书;然亦远斥候,未尝遇害。程不识正部曲、行、伍、营陈,击刁斗,士吏治军簿至明,军不得休息;然亦未尝遇害。不识曰:“李广军极简易,然虏卒犯之,无以禁也;而其士卒亦佚乐,咸乐为之死。我军虽烦扰,然虏亦不得犯我。”然匈奴畏李广之略,士卒亦多乐从李广而苦程不识。

从这段记载可以看到,李广和程不识,一宽一严,但都能达到御敌的效果。但从人性化及受欢迎程度上来讲,李广显然要胜出很多,士卒“乐从”、“乐为之死”,这是领兵很高的境界,也是很多名将共同的优良品质,在史书中大书特书。因此,读过这个对比,对飞将军的敬佩更进了一层。

但是,在《资治通鉴》中,这段之后,司马光紧接着就是一段点评:

臣光曰:《易》曰:“师出以律,否臧凶。”言治众而不用法,无不凶也。李广之将,使人人自便。以广之材,如此焉可也;然不可以为法。何则?其继者难也;况与之并时而为将乎!夫小人之情,乐于安肆而昧于近祸,彼既以程不识为烦扰而乐于从广,且将仇其上而不服。然则简易之害,非徒广军以禁虏之仓卒而已也!故曰“兵事以严终”,为将者,亦严而已矣。然则效程不识,虽无功,犹不败;效李广,鲜不覆亡哉!

这个点评点出了很重要的一点,对心中的一个疑问“宽和严,到底哪种方法好?”有了很好的分析。司马光首先肯定了李广的才能,承认以李广的才能完全可以这么做,但这种做法不能作为学习的榜样,因为他的继任者很难办。

这点太重要了,李广凭借其个性和才能,能成功统帅这只军队,但他的下一任怎么办呢?这样的个性和才能其他人是很难有的,或者说不可能有的,习惯了这种领导方式的士兵很难被其他将军统领。以至于无法保证持续的战斗力。

这也许也部分解释了“李广难封”的原因。

2007-07-02

Cunningham's CRC for OOD training

做开发的恐怕没有人不知道“面向对象”这个词,虽然对其不感冒的人也是有的,但毕竟是极少数,大部分程序员还是极力拥抱“面向对象”的。您要是指责某人不懂“面向对象”,非跟你急不可。

对于“面向对象”的特性和特征,大部分人应该还是说的上来的,但要说动手练练,那又是另外一回事了,“挂羊头卖狗肉”者大有人在,即用“面向对象”语言写着“过程式”程序,还一口咬定“我这就是货真价实的‘面向对象’,假一赔十!……”

其实,这也不能怨这些人,老师就这么教的,即使老师没有这么教,也没有说不能这样做,国内教科书也一样,简单堆砌了一些概念就以为“面向对象”结束了,结果的确学会了“类”、“成员变量”、“方法”……并且也能和以前用“过程”语言(如C语言)一样写出程序来,一样能跑通,于是简历上就加了一项“精通面向对象程序开发……”

曾经也经历过这个阶段,还用这种方式写出不少代码,这些代码还进入了正式系统 -_-!

最终的迷途知返是因为看了一些国外牛人的书,再加上之前摸爬滚打过程中的体验,才在“原来如此!”的惊叹中明白自己原来根本没有懂过“面向对象”,继而庆幸这些没有白读。

如下是一篇OOD文章中的片段,其中有一部分介绍了如下的CRC面向对象设计教学法,眼睛为之一亮:“今儿这文章没白读”

In 1989, Kent Beck and Ward Cunningham taught classes on OO design, and they had problems getting people to abandon the get/set mentality. They characterized the problem as follows:

The most difficult problem in teaching object-oriented programming is getting the learner to give up the global knowledge of control that is possible with procedural programs, and rely on the local knowledge of objects to accomplish their tasks. Novice designs are littered with regressions to global thinking: gratuitous global variables, unnecessary pointers, and inappropriate reliance on the implementation of other objects.

Cunningham developed a teaching methodology that nicely demonstrates the design process: the CRC (classes, responsibilities, collaboration) card. The basic idea is to make a set of 4x6 index cards, laid out in three sections:

  • Class: The name of a class of objects.
  • Responsibilities: What those objects can do. These responsibilities should focus on a single area of expertise.
  • Collaborators: Other classes of objects that can talk to the current class of objects. This set should be as small as possible.

The initial pass at the CRC card is just guesswork—things will change.

Beck and Cunningham then picked a use case and made a best guess at determining which objects would be required to act out the use case. They typically started with two objects and added others as the scenario played out. They selected people from the class to represent those objects and handed them a copy of the associated CRC card. If they needed several objects of a given class, then several people represented those objects.

The class then literally acted out the use case following these rules:

  • Perform the activities that comprise the use case by talking to one another.
  • You can only talk to your collaborators. If you must talk to someone else, you should talk to a collaborator who can talk to the other person. If that isn't possible, add a collaborator to your CRC card.
  • You may not ask for the information you need to do something. Rather, you must ask the collaborator who has the information to do the work. It's okay to pass to that collaborator information he needs to do the work, but keep this interaction to a minimum.
  • If something needs to be done and nobody can do it, create a new class (and CRC card) or add a responsibility to an existing class (and CRC card).
  • If a CRC card gets too full, you must create another class (CRC card) to handle some of the responsibilities. Complexity is limited by what you can fit on a 4x6 index card.

A recording made of the entire conversation is the program's dynamic model. The finished set of CRC cards is the program's static model. With many fits and starts, you can solve just about any problem this way.