[原文地址]：http://www.infoq.com/cn/news/2010/12/bad-code-project-failure
[感想]：
虽然bob大叔说的“糟糕的代码所带来的成本之大足够让一个项目失败”有道理，而且我本人非常非常喜欢他的《clean code》，但我还是认为他过于极端了，过于强调整洁代码本身的作用了。但这真的不是问题症结的源头。
Alex Chaffee 说的“糟糕的管理和需求根本无法通过优质的代码来弥补。”我非常认同。不要对管理过于宽容，而对工程师过于苛责了，两方面都需要有所约束，有一个平衡的游戏规则，游戏才玩得下去。如果对于管理没有要求，把所有要求全压到工程师代码的高品质上，其实是对管理的纵容，对工程师的压迫，就好比有１００斤的货物，有管理者和工程师两人可以去负担，但管理者一点货物也不愿担，全交给工程师一个人去担了。是的，工程师应该有肯吃苦的美德（提高工作的品质），但这并不意味着，“你人好，我就可以没顾忌地欺负你“，把所有货物全让你一个人挑了，你累趴下了，我不但不反省自己为什么不帮忙，反而还怪你吃不了苦！bob大叔虽然想强调工程师应该有吃苦精神，但似乎尺度有点过了。
如何平衡软件开发中各种不同角色的权利和义务呢？我觉得ｓｃｒｕｍ就非常好，用一套游戏规则去平衡各方的力量，不至于失衡。产品负责人可以提需求，但不能在开发周期内改需求，如果一定要改，行，中止当前sprint，延误的工期由你来承担。scrum master不能命令开发团队如何去工作，他只能为团队提供帮助，他的权力是间接的。开发团队在这样一套游戏规则里，才有可能得到保护，才真正有可能高效地开发软件，不会中因糟糕的管理而导致项目失败。