标题：代码之道
代码之道
原 书 名：I. M. Wright's Hard Code
原出版社：Microsoft Press
作　 者：(美)Eric Brechner 
译　者： 陆其明
丛 书 名：Microsoft核心技术丛书
出 版 社：机械工业出版社
书 号： 9787111251675
页 码：192 
定 价：36.00
编辑推荐
《代码大全》姊妹篇！
微软公司内部所有工程师的必读之书！ 
——Peter Isensee，微软公司开发经验
“我能肯定，I.M.Wright不会听我的话，试都不用试。”
——Jon DeVaan，微软公司高级副总裁
“尽管我绝不会从这家伙手里买二手车，但在软件开发方面，他确实也对他自己的东西知道得一清二楚。”
——Ian Ellison-Taylor，微软公司工程部总经理
“微软公司内部所有工程师的必读之书。”
——Peter Isensee，微软公司开发经理
揭示关于编码、测试和项目管理的残酷现实——一位微软的内部人士如实地向你述说。I.M.Wright的“Hard Code”故意煽情，几年来在微软内部成千上万的工程师之间引起了激烈的争论。现在（也顾不上“家丑不外扬”了），我们把他的观点向所有人公开。
本书收录了49个栏目。Eric Brechner重拳出击，对最令他苦恼的问题提出了最佳实践的解决方案，另外还加上了他坦诚的注解。他解剖了开发过程，审查了棘手的团队问题，批判了软件业务的运转方式——自始至终充斥着机灵的幽默和讥讽的风趣。他的想法并不总是很受欢迎（他也不关心那个），但它们的的确确激发起了人们的讨论和想象，推动着软件相关的活动走向卓越。
了解未经掩饰的真相：
怎样提高软件的质量和价值——从设计到安全；怎样切合实际地管理项目的时间表、风险和规范书，怎样为常见的低效率开发瘦身，怎样应用过程改进方法——避免固执盲从，怎样驱动一个成功的、令你自己满意的职业生涯，怎样不变成暴君——发展并管理一个欣欣向荣的团队！
作者简介
Eric Brechner，微软公司“卓越开发”部门的总监，在软件行业已经积累了20多年的经验。他从2001年开始写“Hard Code”栏目，作为一种资源提供给微软的员工。自那以后，其观点栏目在微软内部成千上万的软件开发者之间，激起了无休无止的关于最佳实践的讨论——如今，这些观点走出了微软，走向了整个开发社区。
简介
献给当初对我说“为什么不由你来写？”的人：Bill Bowlus
你手上拿着的是一本关于最佳实务的书。它会比较乏味。但也许会比较有意义，你能从中得到知识，读后甚至对你产生些许影响，但读起来肯定还是干巴巴而无趣的。为什么这么说呢？
最佳实务的书是乏味的，因为这个“最佳”是跟具体的项目、具体的人、他们的目标以及偏好紧密相关的。一个实务是不是“最佳”，大家可能看法不一。作者必须把实务列举出来让读者自己来选，并分析在什么时候、因为什么原因作出最佳选择。虽然这种做法是现实的、负责任的，但也是令人厌烦的，最终无法取悦读者。为释疑而设计的案例研究会使文字有味一些，但作者仍必须把选择的机会留给读者，否则作者就会显得傲慢、教条并且死板。
然而人们喜欢看到傲慢、教条、死板的学者之间的针锋相对。大家喜欢引用学者们的观点片段，与朋友和同事一起讨论。为什么不把这些最佳实务当作观点栏来争论呢？惟一的条件，就是要有人愿意将自己扮演成一个思想保守的傻瓜。
本书的由来
2001年4月，在我历经了Bank Leumi、Jet Propulsion Laboratory、GRAFTEK、Silicon Graphics、Boeing等公司总共16年的职业程序员生涯，再在微软做了6年的程序员和经理之后，我转入了微软内部的一个以在公司范围内传播最佳实务为职责的团队。当时这个组正在运作发行名叫《Interface》月刊网络杂志的一个项目。它很有意义，且富有知识性，但同样也是干巴巴而无趣的。我那时建议增加一个观点栏目。
我的上司Bill Bowlus建议由我来写。我拒绝了。作为一个半大孩子，我努力成为一个协调员，撮合多方产生成果。成为一个爱唠叨的实务学者会毁掉我的名誉和效力。因此，我当时的想法是说服一个大家公认的小心眼的工程师来写，他可能是我在微软以前6年工作经历中接触过的一位固执的开发经理。
但Bill指出，我有22年的开发经验，4年的开发管理经验，写作技巧也还行，而且有足够的态度来做这件事。我只需要放下自身的心理包袱。另外，其他的开发经理都忙于常规的工作，不可能每个月来为我们写观点。最后Bill和我想出了一个用假名撰稿的点子，于是I. M. Wright的“Hard Code”栏目诞生了。
从2001年6月开始，我使用“I. M. Wright，微软逍遥的开发经理”这个署名为微软的开发者和他们的经理写了49个“Hard Code”观点栏。这些栏目的标签行都打上了“绝对诚实，重拳出击”的标语。每个月，成千上万的微软工程师和经理都在读这些栏目。
前16个栏目在《Interface》内部网络杂志上发表了。随后同事（Mark Ashley和Liza White）给我分配了更多的主题。我和《Interface》的美工Todd Timmcke还一起制作了作者的很多搞怪照片。当网络杂志停刊的时候，我才得以喘息的机会，但也停止了写作。
14个月之后，在我们组的同事Amy Hamilton (Blair)、Dia Reeves、Linda Caputo、Shannon Evans和Marc Wilson的帮助下，我又开始在内部站点上发表我的栏目。去年11月份，我将所有的栏目转移到了一个内部的SharePoint博客上。
2007年春天，正当我打算休掉几年前奖励给我的假期的时候，我现在的经理Cedric Coco给了我在休假期间将“Hard Code”出版成书的授权。而微软出版社的Ben Ryan也同意了。
除了我已经提及的人，我还想感谢《Interface》的其他成员（Susan Fario、Bruce Fenske、Ann Hoegemeier、John Spilker和John Swenson），其他帮助过本书出版的人（Suzanne Sowinska、Alex Blanton、Scott Berkun、Devon Musgrave和Valerie Wolley），支持我的管理层（Cedric Coco、Scott Charney和John Devaan），我现在的和以前的、复审过我的栏目并提出过很多主题的团队成员（William Adams、Alan Auerbach、Adam Barr、Eric Bush、Scott Cheney、Jennifer Hamilton、Corey Ladas、David Norris、Bernie Thompson、James Waletzky、Don Willits和Mitch Wyle），我才华出众的中学英语老师（Alan Shapiro），以及那些慷慨给予我反馈的读者们。特别地，我还要感谢我的妻子Karen和我的儿子Alex和Peter，他们让我做任何事情都充满信心。
本书的读者
组成本书的49个观点栏最初是写给微软的开发者和他们的经理看的，尽管它们也是我过去在软件行业6个不同的公司、28年的工作经验中提炼出来的。编辑和我一起修正了表达语言，注解了那些微软内部的特殊用语，使得本书适合于所有软件工程师和工程经理阅读。
我在这些栏目中表达的观点是我个人的，不代表我现在和以前任职过的任何一家公司，包括微软。我在栏目中的注解以及本简介中的言论同样都是我个人的，与公司无关。
本书的组织方式
根据主题的不同，我把所有栏目分成了10个章节。前6章剖析了软件开发流程，接下来3章重点讨论人的问题，最后1章批判软件业务运转方式。用于解决这些问题的工具、技巧和建议遍布全书。本书的最后还附有术语表和索引方便大家参考。
每一章的各个栏目均按照当初在微软内部发表的时间顺序排列。每章开头我都给出了一个简短的介绍，随后就是当初我以I. M. Wright名义发表的栏目内容。编辑成书的时候，我还适时在栏目中加上了“作者注”，以解释微软的术语，提供更新内容或者额外的背景知识。
编辑和我尽力保持了原有栏目的完整性。我们做的，仅仅是纠正语法和内部引用。称得上改动的其实只有一处：就是将原来一个叫“你被解雇了”的栏目标题改成了“最艰难的工作”，因为以前那个标题太容易让人误解了。
每个栏目都以一段激昂的演说开场，然后就是问题根源的分析，最后以我对这个问题如何改善的建议结束。我酷爱文字游戏、头韵和通俗文化，因此栏目中充斥着对这些东西的引用。特别是大部分栏目的标题和副标题都直接取材于歌词、电影对白和有名的谚语。是的，我自娱自乐，但撰写这些栏目确实给我带来了些许乐趣以及痛快的宣泄。希望你也会喜欢！
系统要求
本书提供的工具都是微软的Office Excel 2003和Office Word 2003格式的。只要你的电脑上安装有Word和Excel的浏览器，你就能使用这些文件。
微软的组织结构
因为这些栏目最初是写给微软的内部员工看的，因此简要了解一下微软以及我在工作中扮演的角色会有助于更好地理解这些文字。
目前，微软的产品开发分成三大业务部门，总共有大概25条产品线，超过450个产品单元，和众多的功能团队。这些部门是平台产品与服务部门、微软商业部门、娱乐与设备部门。部门内的产品线是由相关的产品套件整合在一起形成的，比如Office System和Visual Studio。
每条产品线包含了大约20个独立的产品单元。通常情况下，这些产品单元共享源代码控制、建造、安装、工作条款跟踪和项目协调，包括价值主张、里程碑安排、发布管理和工程支持。除了这些协调服务之外，产品单元还有高度的自主权，可以对产品、流程和人员作出自己的安排。
一个典型的产品单元通常有一个产品单元经理（PUM，Product Unit Manager）和三个工程工种经理：部门项目经理（GPM，Group Program Manager）、开发经理（Development Manager）和测试经理（Test Manager）。其他工程工种，比如用户体验、内容发布（比如在线帮助）、实施，可能单独对某个产品单元负责，也可能在产品线或者整个部门中共享。
每个工种都要抽出一个或多个代表，以组成一个叫功能团队的虚拟组织，来开发具体的产品功能。这些人的工作仍然汇报给各自的工种经理。有些功能团队选择敏捷方法，有些喜欢精益模型，有些采用传统的软件工程模型，有些则根据实际情况混合了上述多种方法。
微软怎么能包容所有这些多样性和产品的区域自治、还能为朝着一个共同的目标有效地工作呢？这就要靠产品线公共的项目协调了。举例来说，产品线的价值主张为所有的产品单元和他们的功能团队设置并统一关键应用范例、质量尺度和框架体系。
为了促进跨部门和产品线的协调和共享，特别是为提高质量和效率，微软还设立了一个组织叫Microsoft Trustworthy Computing and Excellence。它是我的上级组织。具体来说，我的工作职责是，要让微软全球超过1万名的开发者在构建令人兴奋的、高质量的用户体验时，能够做得更加开心、更富有效力。不用说，这是一项长期的工作。
我的团队每月将开发部门的领导层聚集在一起，谈论问题并指导我们的工作。我们研究公司范围内乃至整个行业内的工程方法，以期找到新的机会和领域去提高。我们通过网络共享工具、最佳实务，以及实施职业生涯指导。我们举办各种活动和奖项评比，与各种团队商讨，为开发中的各个级别、各种角色提供技术培训。非常棒的工作！另外，我每月还在写着观点栏。
示范工具和文档
在线资料列表
工具 栏目 章节
Sprint backlog: SprintBacklogExample.xls; 
SprintBacklogTemplate.xlt 敏捷子弹 2
Product backlog: ProductBacklogExample.xls; 
ProductBacklogTemplate.xlt 敏捷子弹 2
Spec template: Spec template.doc 糟糕的规范书：该指责谁？ 3
Spec checklist: Spec checklist.doc 糟糕的规范书：该指责谁？ 3
Pugh Concept Selection:PughConceptSelectionExample.xls; 
PughConceptSelectionTemplate.xlt 复审一下这个 5
Inspection Worksheet: InspectionWorksheetExample.xls; InspectionWorksheetTemplate.xlt 复审一下这个 5
Interview Role Playing, a how-to guide: 
InterviewRolePlaying.doc 面试流程之外 9
本书的支持
为了保证本书及其附属内容的准确无误，我们尽了最大的努力。本书所有的修正和改动都会搜集起来并放到微软的知识库中去。
问题和意见
如果你对本书及其附属内容有任何意见、建议或问题，并且通过访问上述站点仍然无法解决，请给微软出版社发送电子邮件，或者按照如下方式邮寄：
Microsoft Press
Attn: I. M. Wright’s “Hard Code” Editor
One Microsoft Way
Redmond, WA 98052-6399
请注意，上面的地址对微软的软件产品不提供支持。
目录
序
简介
第1章 项目的不当管理
2001年6月1日：“开发时间表、飞猪和其他幻想”
里氏震级估计
风险管理
客户赢了
2001年10月1日：“竭尽所能：再论开发时间表”
软件工程绝对是含糊的
相信一半你看到的，别信你听到的
激励：不能光靠比萨和啤酒
在日期上沉沦
2002年5月1日：“我们还开心吗？分诊的乐趣”
战争是地狱
这不是个人的事情
分诊的5条黄金法则
魔鬼藏在细节里面
很难进行下去，不是吗？
谨小慎微
2004年12月1日：“向死亡进军”
暗箭伤人
对失败的连祷
转折点
很少有人走过的路
2005年10月1日：“揭露真相”
遭受错觉之苦
拿把叉子扎进我的身体
给我个坦率的回答
给猪抹口红
看看所有这些传言
我想知道真相
第2章 过程改进，没有魔法
2002年9月2日：“六西格玛？饶了我吧！”
啊！这是什么巫术？！
召集骑兵
在混沌之外建立秩序
2004年10月1日：“精益：比帕斯雀牛肉还好”
任何事情都要适中
俭则不匮
过量生产
走向深处
运输
多余动作
等待
过程不当
库存
缺陷
合作共生
2005年4月1日：“客户不满”
但愿不知道
太过分，太迟了
敏捷错觉
回退你的步伐
更多用武之地
使用正确的工具
布基胶带和打包钢丝
客户满意
2006年3月1日：“敏捷子弹”
真理的敌人
拨乱反正
准备改变了吗？
让他说话
你完善我
有点极端
准备玩橄榄球！
最后你要知道的
第3章 根除低下的效率
2001年7月1日：“迟到的规范书：生活现实或先天不足”
对于每次变更，搅动，搅动，搅动
走廊会议
委员会议
规范书变更请求
预防是最好的治疗
2002年6月1日：“闲置人手”
宝宝做了件极坏的事情
告诉我该做什么
俭则不匮
2004年6月1日：“我们开会的时候”
为什么我们会在这里？
我们正在试图做什么？
为什么他们会在这里？
为什么我现在才听到这个？
接下去要做什么？
2006年7月1日：“停止写规范书，跟功能小组呆在一起”
你失去理智了吗？
在那里进退两难
特殊要求
我不记得了
坚持做一件事情
你准备好了吗？
2007年2月1日：“糟糕的规范书：该指责谁？”
树立靶子
沟通分解
保持简单容易
变得稳健
获取反馈
集成质量检查
差别在哪？
第4章 跨越工种
2002年4月1日：“现代临时夫妇？开发与测试”
我怎么爱你？让我来数一下有多少种方式
必要的邪恶或珍贵的伙伴？
每个人都要知道自己的弱点
你完善我
2004年7月1日：“感觉性急——测试者的角色”
高级保护
改变一下对你有好处
黎明时分
充分利用数据
非常酷——我保证你
2005年5月1日：“模糊逻辑——君子之道”
包罗万象
他们跟我们不一样
通过安检
着手去改变
更好地在一起
2005年11月1日：“废除工种——有什么理由搞专业化？”
历经未来的日子
考察它的极限
足球是门科学
两者之间的距离
你深陷其中
第5章 软件质量不是梦
2002年3月1日：“你对你的安全放心吗？”
小心晃动的钟摆
做正确的事
安全受制于最薄弱环节
领导、跟随或者离开
2002年11月1日：“牛肉在哪里？为什么我们要质量”
情况变了
足够好还不行
艰难的选择
终于有足够的时间了
再检查一遍
医生，治好你自己的病
步步为营
太多疑问？
2004年4月1日：“软件发展之路——从手工艺到工程”
工艺制桌子，工程造汽车
其实你知道
真实面对自己
数字的含义
各人有各人的习性
大处着想，小处着手
从优秀到卓越
2005年7月1日：“复审一下这个——审查”
糟糕的混合
完美风暴
谁来负责？
你有什么想法？
正是这个形式
孩子，准备好了吗？
再检查一遍
神奇的汇总会议
审查的诀窍
走上正道
2006年10月1日：“对质量的大胆预测”
谜？我不这么认为
邪恶双煞
嫌疑惯犯
你会喜欢它的
停止卖弄愚蠢
质量就是没有意外
第6章 有时间就做软件设计
2001年9月1日：“错误处理的灾难”
恐怖，恐怖
使用异常
别丢弃，用上它！
2002年2月1日：“厨师太多烧不好菜——惟一权威”
一幅图片抵得上一千个字
有人确切知道现在几点了吗？
只能有一个
万物皆有联系
2004年5月1日：“通过设计解决”
如何才算足够好？
设计完成
细节，细节
让我看看你是由什么组成的
当心缺口
成功处方
2006年2月1日：“质量的另一面——设计师和架构师”
你必须比那做得更好
改变一下对你有好处
他这么做不对
正确的做法
下一次，试试雕塑
关键要有正确的工具
打破这些壁垒
2006年8月1日：“美妙隔离——更好的设计”
分解难做
正确的做法
团队不需要“我”
循序渐进
猫狗不分家
第7章 职业生涯历险
2001年12月1日：“当熟练就是目标”
每个人都要知道自己的弱点
享其成但不坐等
我希望他们尊重我
我们都牵连其中
2002年10月1日：“生活是不公平的——考核曲线”
我不想再逆来顺受了
知识就是力量
关注业务
前进，让我快乐
伸出手去接触某人
有了柠檬？制作柠檬水
改变你的主意
方向盘后面的人
2006年11月1日：“职业阶段中的角色”
一个人同时扮演很多角色
搞清楚职业阶段
我是有抱负的
资历过高
我是特殊的
只能选一个
你想成为什么？
2007年5月1日：“让你自己与世界相连”
你认识的人
我利用习惯
难道你不好奇？
你得到了我们的感谢
我回头再找你
欢迎来到这个世界
第8章 自我完善
2002年12月1日：“要么听我的，要么走人——协商”
一个你无法拒绝的方式
逐渐长大
我脑子里闪过的阴影和凶兆
不要伤害Messenger
皆大欢喜
2005年2月1日：“最好学会平衡生活”
平衡是关键
光说不练
我甚至不能平衡我的支票簿
平衡好，一切都好
2005年6月1日：“时间够用了”
直接告诉我
免受打扰之苦
找到你的乐园
我们谁也不笨
我们必须共同承担
告诉我必须做什么
他还是个孩子
你应该休息一下
这里秩序井然
坦诚相待
大有可为
2005年8月1日：“有理有节地控制你的上司”
我没辙了
知彼知己
他们能自我适应
把水卖给鱼
势利的眼睛
付诸行动
敢于做梦
2006年4月1日：“你在跟我说话吗？基本沟通”
为我着想一下
告诉我你想要什么
你什么时候想要？
缩小注意力跨度
就这样完了？
2007年3月1日：“不只是开放和诚实”
那不是理由
我会对你诚实
那不容易
他们似乎有个开放政策
无处隐藏
跟我想的不一样
走上正道
第9章 成为管理者，而不是邪恶的化身
2003年2月1日：“不只是数字——生产力”
小心你希望得到的东西
扮演一个角色
卓越开发者的素质
你要做法官
2004年9月1日：“面试流程之外”
抱怨得不到帮助
90%是准备
那就是问题
白板编译器
帮招聘专员准备
再次帮面试官准备
友情提醒
最后的难题
2004年11月1日：“最难做的工作——绩效不佳者”
你期望什么？
知难而进
寻求专业援助
没人想失败
目标是成功
无所求，则无所获
你不会总能如愿
2005年9月1日：“随波逐流——人才的保持和流动”
我只是想环球旅行
不错的水坝？
像河水一样流动
新鲜血液
分享就是关爱
成长空间
我必须要旅行
放任自流
2005年12月1日：“我能够管理”
持续送出的赠品
优秀就够了
草率行事
我想要工作
我不是东西
从优秀到卓越
我服务于人
2006年5月1日：“不恰当的比较——病态团队”
想要挑起战争
这不是竞争
我会给你些提示
团结在一起
第10章 微软，你会喜欢它的
2001年11月1日：“我是怎么学会停止焦虑并爱上重组的”
沿着巴别塔下来
地狱里的生活
很少有人走过的路
容忍问题还是主动去解决？
2005年3月1日：“你的产品单元经理是个游民吗？”
有计划的人
我等不及要去实施了
魔鬼藏在细节里面
道路规则
回到正确的跑道上
2006年9月1日：“有幸成为Windows的主宰者”
你还有别的要求吗？
准备轮船
设置路线
启航
导航
责任
下一代Windows
2006年12月1日：“Google：严重的威胁还是糟糕的拼写？”
他们步伐踉跄，我们手舞足蹈
注定要失败
聪明人需要智能客户端
保持警惕
一马当先
2007年4月1日：“中年危机”
你已经变了
日子照过，只不过要掌握一点窍门
不轻易冒险
我认为他们还不能胜任
不再年轻了
不要惊慌失措
没有人是完美的
术语表
推荐序
读者对I. M. Wright’s “Hard Code”栏目的喝彩
任何大型组织都有危险成为自身文化的牺牲品。关于世界应该是什么样子或者事情应该怎样去做的神话，最后证明都是一个个自圆其说的预言。任何组织都会有这种倾向，但它对于需要不断创新才能繁荣的技术公司来说，却是个致命杀手。Eric Brechner做了件难以置信的事——他亮出了手术刀，深深地切入了组织内部看似无关紧要的东西。他毫不吝啬地打出了重拳——偶尔也会故意玷污自己的名声。尽管有一些隐语和例子对于微软内部的员工更有吸引力，但他的智慧和至理名言，大都可以成为整个软件行业的财富。
——Clemens Szyperski，首要架构师
“I. M. Wright”写的关于开发时间表的文章真的是太棒了！它在我所属部门参与的基础设施项目上同样适用。
——Ian Puttergill，部门经理
你没有受到任何死亡威胁，是吗？
——Tracey Meltzer，高级测试主管
这一定是个笑话——很坦率地说，这类纯粹的谬论危机四伏。
——Chad Dellinger，企业架构师
Eric是我本人崇拜的英雄——很大程度上是因为他长期以来一直代表着开发社区的一种声音。
——Chad Dellinger，企业架构师
软件工程师很容易就会迷失在他们的代码中，甚至更糟糕的是，他们迷失在过程中。那正是他们迫切需要Eric在“Hard Code”中提出的实用建议的时候。
——David Greenspoon，总经理
我刚刚读完这个月的栏目……我不得不指出，这是我第一次认为你正在推行一个对公司完全错误并且带有灾难性的想法。
——David Greenspoon，总经理
Eric你真了不起 几个月之前，我跟我的产品单元经理和一些开发主管恰恰进行过这样的一次对话。
——Scott Cottrille，首要开发经理
我真的很喜欢这些栏目。它们是如此实用，而且还很全面！我喜欢它们的另外一个原因是，当我在指导初级开发人员的时候，我可以把这些栏目推荐给他们；他们也会记住这些栏目，因为它们都是那么地有趣。
——Malia Ansberry，高级软件工程师
Eric，干得好！我觉得你在这个栏目中说得非常中肯。我想，该给管理者传递这样的信息，“不要害怕试验。”事情的真实情况跟理想化的理论之间差别是非常大的。
——Bob Fries，合作伙伴开发经理
我只是想让你知道我有多喜欢你写的文字——它们充满智慧、见解深刻，你还神奇地把本来很严肃的问题变得如此有趣（采用的方法很不错）。
——Niels Hilmar Madsen，开发者传教士
你那篇关于死亡行军的栏目来的正是时候。我们正打算在未来几周内开会讨论功能削减的事情呢！那些我们以前付出很大代价才学到的教训，不知怎么回事，总是轻易就被忘记了；你的栏目对大家起到了很好的提醒作用。
——Bruce Morgan，首要开发经理
我想让你知道的是，我真的很喜欢并感谢你在EE站点上发表的所有文章。不过，直到今天，当我读了“停止写规范书”这个栏目之后，我不得不说，我强烈不同意你的观点。
——Cheng Wei，项目经理
你到底是谁？你跟Eric Brechner都做了些什么？
——Olof Hellman，软件工程师
Eric，我刚刚读完你写的那篇叫“不恰当的比较”的文章。你不知道我有多感激你！你实际上把这个观点传达给了公司里面成千上万的人……你致力于正确领导和管理团队，并把其中的奥秘跟大家分享，对于你的这种热情我真的非常欣赏！
——Teresa Horgan，商务项目经理
媒体评论
专家评价：
“我能肯定，I M Wright不会听我的话，试都不用试。” 
——Jon DeVaan，微软公司高级副总裁
“尽管我绝不会从这家伙手里买二手车，但在软件开发方面，他确实也对他自己的东西知道得一清二楚。”
——Ian Ellison-Taylor，微软公司工程部总经理
“微软公司内部所有工程师的必读之书。”
——Peter Isensee，微软公司开发经理
揭示关于编码、测试和项目管理的残酷现实——一位微软的内部人士如实地向你述说。I M Wright的“Hard Code”故意煽情，几年来在微软内部成千上万的工程师之间引起了激烈的争论。现在（也顾不上“家丑不外扬”了），我们把他的观点向所有人公开。
本书收录了49个栏目。Eric Brechner重拳出击，对最令他苦恼的问题提出了最佳实践的解决方案，另外还加上了他坦诚的注解。他解剖了开发过程，审查了棘手的团队问题，批判了软件业务的运转方式——自始至终充斥着机灵的幽默和讥讽的风趣。他的想法并不总是很受欢迎（他也不关心那个），但它们的的确确激发起了人们的讨论和想象，推动着软件相关的活动走向卓越。
读者评价：
读者对I M Wright’s “Hard Code”栏目的喝彩
任何大型组织都有危险成为自身文化的牺牲品。关于世界应该是什么样子或者事情应该怎样去做的神话，最后证明都是一个个自圆其说的预言。任何组织都会有这种倾向，但它对于需要不断创新才能繁荣的技术公司来说，却是个致命杀手。Eric Brechner做了件难以置信的事——他亮出了手术刀，深深地切入了组织内部看似无关紧要的东西。他毫不吝啬地打出了重拳——偶尔也会故意玷污自己的名声。尽管有一些隐语和例子对于微软内部的员工更有吸引力，但他的智慧和至理名言，大都可以成为整个软件行业的财富。
——Clemens Szyperski，首要架构师
“I M Wright”写的关于开发时间表的文章真的是太棒了！它在我所属部门参与的基础设施项目上同样适用。
——Ian Puttergill，部门经理
你没有受到任何死亡威胁，是吗？ 
——Tracey Meltzer，高级测试主管
这一定是个笑话——很坦率地说，这类纯粹的谬论危机四伏。