《构建之法》一书已完成了第一遍的阅读，接下来，我将随机抽取其中的一段进行精读。
移山公司的项目进行了一段时间，TFS上也积累了不少数据。大栓做了“数据挖掘”，整理出来一些统计信息，向各位领导汇报。
大牛：哇！前端组的这位开发人员是冠军呀，他导致的Bug总量约等于所有其他成员的总和。
二柱：那是有客观原因的，你可能不知道他的工作量是最大的。
大牛：那也不能因此产生这么多Bug，而让整个团队的进度停下来吧。
二柱：别人工作得这么辛苦，我倒是不太忍心再批评他。阿超，其实我觉得我们应该鼓励成员多做贡献，错误总是难免的，但是你知道他上星期完成了两个功能，明显比别人快多了。别的同事和他一比，就慢多了。
大牛：我不太同意，从TFS的数据来看，他的Bug数量远比别人多，而且不少Bug都有一段时间了，你说的“慢”的人，好像没有多少Bug，也是差不多按期完成的。问题是你希望团队成员是“萝卜快了不洗泥”型的，还是“慢工出细活”型的？
阿超：我有一个故事，假设团队里来了两位年轻人，嗯，就叫“萝卜”和“白菜”。萝卜做事很快，是“萝卜快了不洗泥”类型；白菜是“慢工出细活”类型。分配了任务后，萝卜很快就说做好了！白菜还在吭哧吭哧地跟项目经理和测试人员讨论。领导很高兴，让萝卜去做更多的事。开发阶段结束了，萝卜比白菜多做了不少功能。稳定阶段开始了。大家发现萝卜负责的功能出了很多问题，白菜的模块倒是比较稳定。然而萝卜在团队中的曝光率很高，很多问题都在等着他解决，从统计数据上看，他也修复了不少小强。白菜搞定了自己负责的模块，开始帮助其他人，由于不熟悉其他人的模块，白菜修复的缺陷不多。由于萝卜的设计有缺陷，导致模块非常复杂，萝卜也成了唯一了解其模块的开发人员。项目最后阶段，几乎都是萝卜工作得最晚，把最后几个缺陷给修复了。领导们说：有问题，找萝卜！项目结束了，开始了绩效考核，领导A认为白菜绩效不错，模块按时完成，没有大多问题，然后还能帮助其他成员；领导B认为萝卜是超级明星：第一个完成模块，修复的缺陷最多，而且掌握了最复杂的模块，离开他不行，工作得也很晚，有突出贡献。至于白菜，领导B没感觉他做了啥，仅仅是按要求完成任务了。萝卜白菜，各有所爱。那萝卜和白菜谁该得到奖励，谁该得到批评呢？假如领导B的评价方式占了上风，萝卜得到奖励，白菜离开了团队，你觉得下一个版本会出现什么情况？
大牛：我估计萝卜会成为“构建大师”，每天忙得不可开交。然而项目进展不一定会像以前那样顺利……
二柱：有人会怀念白菜。
大牛：你的意思是团队的领导者文化决定了团队的风格。但是当前该怎么办呢？阿超：所以我们要让“萝卜快了不洗泥”的人慢下来，这样能减少他们的危害。大牛：授予他们“萝卜大师”的称号？
阿超：恐怕不行，我们要胡萝卜和大棒并用。我们的大棒就是“小强地狱”（Bug Hell）。
这么一个故事，充分体现了软件开发过程中的“质”与“量”不易兼顾的问题，过于追求“量”，会导致BUG偏多，模块可读性不高，影响整体团队进度等问题；同样地，过于追求“质”，则会在修复BUG上花费较多时间，一样会影响整体的团队进度。但是相比而言，过于追求“量”的情况更多，危害也更大，因此，对这一情况加以限制也显得非常重要。而《构建之法》书中给出的方法便是“小强地狱”，即让导致BUG数量超标者进入小强地狱，期间只允许修复BUG，不允许参与其他开发工作，直到其导致的BUG数量低于阈值为止。这样的方法，只要阈值设置得合理，就可以很有效地使团队成员自觉把控“质”与“量”之间的平衡，从而提升整体团队的工作效率。