需求搞错的严重后果，18英尺的巨石拱门变成了18英寸的石桩子。
最著名也最声名狼藉的匈牙利命名法，可能在用C++写Windows程序的时代是需要，因为各种类型、结构、枚举、控件等等让人眼花缭乱，让人容易出错，而在Java和C#等这种强类型的语言中，这类命名法完全是对程序员审美观的践踏。
prepBut nI vrbLike adjHungarian! qWhat’s artThe adjBig nProblem?
我就是喜欢匈牙利命名法！有什么问题？
Chandler中的所有内容都是Item，对Item可以打戳算是一种创举，有机会看来还是可以试试这款应用。
非常敬佩写标准的人，你要用5年为计量标准的眼光看问题。得花上5年时间，才能得到你真正想要的有用之物。
这里也提到了WebDAV，好像这协议在Mac里实现得比较全，但在Windows中都不完整。omnifocus也支持WebDAV同步。
这章里提到了37Signals公司（写《重来Rework》的那家公司），这种小型团队专注于AJAX的WEB应用，同样取得了成功。
用贴纸法来讨论项目各个小版本应该具有的功能特性，也是敏捷开发里重点推广的。
IBM执行强制进度纪律的成功基于两条原则：
1）计划是强制性的
2）计划必须符合现实情况 ----“从底向上”，依据那些负责按计划执行的程序员的经验和知识而来，而不是“从顶至下”，靠管理者拍脑袋或对市场的期望而来。
CMM这个沉重的软件开发成熟度模型在国内完全变了味，曾看着一个软件公司为了通过CMM4，编出一堆从来无人细看的厚厚的文档，CMM果然只重过程，而国内更把这种过程流于形式，通过CMM，只为了向用户抬高价码。TSP、PSP也看过，感觉相当繁琐，在国内都难于实行。
2001年17位领军人物，提出了敏捷软件开发宣言，向这种笨重的CMM宣战，从此极限编程XP和SCRUM开始流行。
Google让开发者把五分之一的时间花在个人项目上。这种管理方式在国内想都不敢想。
祖尔测试的12个问题：
1）Do you use source control? 你们使用源代码控制吗？
2）Can you make a build in one step? 你们一步就能完成构建吗？
3）Do you make daily builds? 你们做每日构建吗？
4）Do you have a bug database? 你们有缺陷数据库吗？
5）Do you fix bugs before writing new code? 你们会在写新代码之前修复缺陷吗？
6）Do you have an up-to-date schedule? 你们有与当前工作吻合的进度安排吗？
7）Do you have a spec? 你们有规约吗？
8）Do programmers have quiet working conditions? 程序员工作环境安静吗？
9）Do you use the best tools money can buy? 你们采用了市面上最好工具吗？
10）Do you have testers? 你们有测试人员吗？
11）Do new candidates write code during their interview? 你们会要求应聘者在面试时写代码吗？
12）Do you do hallway usability testing? 你们做走廊可用性测试吗？