#30：开发者画蛇添足
开发者会被新科技所吸引，有时会想要在项目开发中尝试一些新的特性，或者参照别的程序里的组件，自己写出它的实现，即使项目没有这样要求。这些设计、实现、测试、撰写文档的经历都是不需要的，且会增长项目进度。
#31：来回推搡的谈判
有一种奇怪的谈判策略，管理者在确认了进度上的失误后，即没有按时完成任务，在进度更改后又加上新的任务。这样做的理由耐人寻味，因为确认了进度上失误的这个管理者也表示承认了项目进度是有错误的。但是当项目进度重新调整正确后，同一个人又用明显的举动将其再一次搞错。这无疑将拖延开发进度。
#32：以研究为中心的项目开发
Cray超级计算的设计师Seymour Cray说，他从来没有试图过同时跨越两个领域进行开发，因为那样做风险太高了（Gilb 1988）。许多软件项目开发人员可以从Cray那里好好学一学。如果你的项目着眼于研究出新的算法或实践方式，那你不是在进行软件开发，你是在做软件研究。软件开发进度是可预测的，而软件研究的进度即使从理论上讲也是不可测的。
如果你的产品目标中包括了研究出新的算法、提高速度、内存使用等，那你得预见项目进度是非常不确定的。如果你的项目中还有其他弱点，如人员的短缺，人员资历不足，模糊的需求，于承包人之间不稳定的接洽，那把项目进度扔到窗外去吧。如果你真的想要完成那些研究，那不要期望进度会很快！
技术
剩下的经典错误是和现代技术的使用和误用有关的。
#33：银弹综合症
在案例分析中，人们把太多的期望寄托在所谓的新技术中（报告生成器，面向对象编程，C++），而它们是否能在此项目中发挥效用还不得而知。当项目开发团队决定使用一种新的方法或技术，其他它能解决目前所面临的问题时，他们一定会非常失望（Jones 1994）。
#34：对新工具和方法太过犹豫
在技术革新时，组织很少会大幅度提高他们的产能，不管他们引进了多少先进的技术。先进的技术所带来的好处基本上不在他们的学习范围之内，而要学 习这些新的技术以发挥其大效能是需要花费时间的。新的技术同时会包含新的风险，只有使用后才会发现。人们宁愿使用慢速的稳定的提高，而不是经历起伏过大 的收获。案例分析3-1中的开发团队应该已经计划到使用了新技术后会使产能提高10%，而不是乐观的相信这会使开发速度提高一倍。
有一个特例，当在使用过去项目的代码时，这种犹豫会更加明显，但时间的节省并没有想像中的多。
#35：在项目开发过程中更换工具
这是一种惯常的备用手段但很少奏效。有时这对于相同产品线内的升级会有效，如3.0版、3.1版甚至4.0版。但其中的因为使用新工具而产生的学习时间、重复劳动和不可避免的错误往往会抵消掉在项目中途更换工具的好处。
#36：缺少自动化的源代码控制
不进行自动化的源代码控制会使关键项目遭 受不必要的风险。如果没有它，当两个程序员在开发同一个部件时，他们需要进行手工整合。他们也许会达成约定，把修改好的文件存入一个主文件夹，并在修改 时注意查看文件时间信息。但是有些人总是会覆盖他人的工作。当人们用过时的结构来编写程序，在发现之后又必须进行重写。当用户举报程序的错误时间，你不 能重新编译项目。源代码平均每个月要更改10%，而手工的源代码控制是跟不上的。
