在所有的弱点中，最大的弱点就是害暴露弱点。
–J.B.Bossuet,Politics from Holy Writ, 1709

依据你的职业发展、你的项目和你每天的工作，为你自己和你的行为负责这样一种观念，是注重实效的哲学的一块基石。注重实效的程序员对他或者她自己的职业生涯负责，并且不害怕承认无知或者错误。这肯定并非是编程最令人愉悦的方面，但它肯定会发生–即使是在最好的项目中。尽管有彻底的测试，良好的文档以及足够的自动化，事情还是会出错。交付晚了，出现了未曾预见到的技术问题。
发生这样的事情，我们要设法尽可能职业地处理它们。这意味着诚实和坦率。我们可以为我们的能力自豪，但对于我们的缺点–还有我们的无知和我们的错误–我们必须诚实。

负责

责任是你主动担负的东西。你承诺确保某件事情正确完成，但你不一定能直接控制事情的每一个方面。除了你尽你所能以外，你必须分析风险是否超出了你的控制。对于不可能做到的事情或是风险太大的事情，你有权不去为之负责。你必须基于你自己的道德准则和判断来做出决定。
如果你确实同意要为某个结果负责，你就应切实负起责任。当你犯错误（就如同我们所有人都会犯错误一样）、不要把所有问题都归咎于供应商、编程语言、管理部门、或是你的同事。也许他（它）们全体或是某几方面在其中扮演了某种角色，但你可以选择提供解决方案，而非寻找借口。
如果存在供应商不能按时供货的风险，你应该预先制定一份应急计划。如果磁盘垮了—带走了你的所有源码—而你没有备份，那是你的错。告诉你的老板“我的源码让猫给吃了”也无法改变这一点。
Provide Options，Dont’t Make Lame Excuses — 提供各种选择，不要找蹩脚的借口
在你走向任何人、告诉他们为何某件事做不到、为何耽搁、为何出问题之前，先停下来，听一听你心里的声音。与你的显示器上的橡皮鸭交谈，或是与猫交谈。你的辩解听起来合理，还是愚蠢？在你老板听来又是怎样？
在你的头脑里把谈话预演一遍。其它人可能会说什么？他们是否会问：“你试了这个吗？”，或是“你没有考虑那个吗？”你将怎样回答？在你去告诉他们坏消息之前，是否还有其它你可以再试一试的办法？有时，你其实知道他们会说什么，所以还是不要给他们添麻烦吧。
要提供各种选择，而不是找借口。不要说事情做不到；要说明能够做什么来挽回局面。必须把代码扔掉？给他们讲授重构的价值，你要花时间建立原型，以确定最好的继续前进的方式？你要引入更好的测试或自动化，以防止问题再发生？又或许你需要额外的资源。不要害怕提出要求，也不要害怕承认你需要帮助。
在你大声说出它们之前，先设法把蹩脚的借口清除出去。如果你必须说，就先对你的猫说。反正，如果小蒂德尔丝要承受指责。。。。
挑战
如果有人–比如银行柜台职员、汽车修理工或是店员—对你说蹩脚的借口，你会怎样反应？结果你会怎样想他们和他们的公司？

软件的熵

尽管软件开发几乎不受任何物理定律的约束，熵（entropy）对我们的影响却很大。熵是一个来自物理学的概念，指是的某个系统中的“无序”的总量。遗憾的是，热力学定律保证了宇宙中熵倾向于最大化。当软件中的无序增长时，程序员们称之为“软件腐烂”（Software rot）。
有许多因素可以促生软件腐烂。其中最重要的一个似乎是开发项目时的心理（或文化）。即使你的团队只有你一个人，你开发项目时的心理也可能是非常微妙的事情。尽管制定了最好的计划，拥有最好的开发者，项目在其生命期中仍可遭遇毁灭和衰败。而另外有一些项目，尽管遇到巨大的困难和接连而来的挫折，却成功地击败自然的无序倾向，设法取得了相当好的结果。
是什么造成了这样的差异？
在市区，有些建筑漂亮而整洁，而另一些却是破败不堪的“废弃船只”。为什么？犯罪和城市衰退领域的研究者发现了一种迷人的触发机制，一种能够很快将整洁、完整和有人居住的建筑变为破败的废弃物的机制。
破窗户。
一扇破窗户，只要有那么一段时间不修理，就会渐渐给建筑中的居民带来一种废弃感——一种职权部门不关心这座建筑的感觉。于是又一扇窗户破了。人们开始乱扔垃圾。出现了乱涂乱画。严重的结构损坏开始了。在相对较短的一段时间里，建筑就被损毁得超出了业主愿意修理的程度，而废弃感变成了现实。
“破窗户理论”启发了纽约和其它大城市的警察部门，他们对一些轻微的案件严加处理，以防止大案的发生。这起了作用：管束破窗户、乱涂乱画和其它轻微违法事件减少了严重罪案的发生。
Don’t Live with Broken Windows——不要容忍破窗户
不要留着“破窗户”（低劣的设计、错误决策、或是糟糕的代码）不修。发现一个就修一个。如果没有足够的时间进行适当的修理，就用木板把它钉起来。或许你可以把出问题的代码放入注释（comment out），或是显示“未实现”消息，或是用虚设的数据（dummy data）加以替代。采取某种行动防止进一步的损坏，并说明情势处在你的控制之下。
我们看到整洁、运行良好的系统，一旦窗户开始破裂，就相当迅速地恶化。还有其它一些因素能够促生软件腐烂，我们将在别处探讨它们，但与其它任何因素相比，置之不理都会更快地加腐烂的进程。
你也许在想，没有人有时间到处清理项目的所有碎玻璃。如果你继续这么想，你就最好计划找一个大型垃圾罐，或是搬到别处去。不要让熵赢得胜利。

灭火

作为对照，让我们讲述Andy的一个熟人的故事。他是一个富得让人讨厌的富翁，拥有一所完美、漂亮的房子，里面满是无价的古董、艺术品，以及诸如此类的东西。有一天，一幅挂毯挂得离他的卧室壁炉太近了一点，着了火。消防人员冲进来救火——和他的房子。但他们拖着粗大、肮脏的消防水管冲到房间门口却停住了——他们要在前门和着火处之间铺上垫子。
他们不想弄脏地毯。
这的确是一个极端的事例，但我们必须以这样的方式对待软件。一扇破窗户——一段设计低劣的代码、团队必须在整个项目开发过程中加以忍受的一项糟糕的管理决策——就足以让项目开始衰败。如果你发现自己在有好些破窗户的项目里工作，会很容易产生这样的想法：“这些代码的其余部分也是垃圾，我只要照着做就行了。”项目在这之前是否一直很好，并没有什么关系。在最初得出“破窗户理论”的一项实验中，一辆废弃的轿车放了一个星期，无人理睬。而一旦有一扇窗户被打破，数小时之内车上的设备就会被抢夺一空，车也被翻了个底朝天。
按照同样的道理，如果你发现你所在的团队和项目的代码十分漂亮——编写整洁、设计良好，并且很优雅——你就可能会格外注意不去把它弄脏，就和那些消防员一样。即使有火在咆哮（最后期限、发布日期、会展演示，等等），你也不会想成为第一个弄脏东西的人。