零指令错误 – Writing solid code
1986年，在为几家小公司咨询和工作了10年之后为了获得编写Macintosh应用程序的经验，我特意到Microsoft公司工作，参加了Macintosh开发小组。这个小组负责Microsoft的图形电子表格应用程序的开发。
当时，我还不能肯定想象的代码是什么样子的，我想也许应该既引入入胜又雅致吧！但我看到的代码却很平常，与我以往见到的其它代码没有什么不同。要知道，Excel有一个相当漂亮的用户界面 ─── 它比当时其它基于字符的电子表格软件更容易使用，更加直观。但使我感受更深的是产品中包含的一个多功能调试系统。
该系统旨在自动地问程序员和测试者进行错误报警。其工作方式非常象波音747驾驶仓内向驾驶员报告故障的报警灯。该调试系统主要用来对代码进行监视，它并不过多地对代码进行测试。虽然现在该调试系统采用的概念已不再新鲜了，但当时它们的广泛使用程度以及该系统有效的查错能力还是吸引了我，使我深受启发。没过多久，我就发现Microsoft的大部分项目都有多功能的内部调试系统，而Microsoft的程序员都高度重视代码中的错误及其产生原因。

在做了两年Macintosh Excel之后，我离开了该开发小组，去帮助另一个代码错误数目超常的小组。在开发Excel的两年中，我发现Microsoft虽然壮大了两倍，但许多老项目组熟知的概念并没有随着公司的壮大而传到新项目组。新程序员不象我加入Microsoft之前时的老程序员一样对容易引起错误的编码习惯特别重视，而只有一般的注意。
在我转到新项目组六个月之后，有一次我对一个程序员伙伴提到：“应该把编写无错代码的某些概念写成文字，使那些原理能在新项目组传开”。这时另一位程序员对我说：“你不要总是想着写文档，为什么你不把这一切都写下来？为什么你不写本书，问问Microsoft出版社是否愿意出版呢？毕竟这些信息不是谁的专利，其作用不过是为了使程序员更加重视错误。”

当时我对这个建议并没有多想，主要原因是没有时间，而且以前我也没有写过书。以前我所做过与写书最有关系的事情，不过是在80年代初协助别人主办Hi-Res杂志的程序设计专栏，这与写书毕竟不是一回事。

正如您所见到的，这本书还是写出来了。理由很简单：1990年，由于错误越来越多，Microsoft取消了一个尚未公布的产品。现在，错误越来越多已经不是什么新鲜事情，Microsoft的几个竞争者都因此取消过一些项目。但Microsoft因为这种原因取消项目，还是头一次。最近，随着接连不断地出现产品错误。管理人员终于开始叫嚷“受不了啦”，并采取了一系列的措施企图将错误率下降到原先的水平。尽管如此，仍然没有人将这些错误因由记录下来。

现在，Microsoft已经比我刚进公司时大了九倍。很难设想，倘若没有准确的指南，公司怎样才能将出错率降低到原来的水平。尤其是在Windows和Macintosh的应用越来越复杂的情况下，更是如此。
以上就是我最终决定写这本书的原因Microsoft出版社已经同意出版这本书。情况就是这样。我希望您会喜欢这本书，我力图使本书不那么枯燥并尽量有趣。


微软研发：致胜策略 － Debugging the Development Process
作者详细描述了他在美国领导项目的各种实际的策略方法，教您如何开发高质量的软件，而且绝不延误。本书中，作者以直率、真诚的笔调 ，与您畅谈在微软中经历过的种种成功与失败，他将告诉您 ：如何增进团队的工作效率，而且让每个人都乐在其中？为什么您曾想把超级程序员赶走？如何避免落入行政程序的天罗地网？有哪些小小的改变，可以获取极大的效益？不必加班就能如期完成软件的秘诀？如何让所有的工作都价值翻倍？如何让团队保持续的创造力？如何提高程序员的整体技术水平？本书是为每一位从事研发工作的朋友而写，相信您在读过本书之后，一定急于推荐给您的主管、同事和您的朋友。