5．接口的设计
在C++中，接口是一个包含所有虚函数的类；而在Java中接口技术被直接支持；在COM和COBRA中，你没有其他选择，你和所有的抽象打交道——所有的都是接口，没有实现。接口提供了一个更加整洁的设计方式。要想让程序员们确信这一点有些困难，但是它对将COM或者COBRA指定为构件模型非常有帮助的（COBRA技术也是与操作系统无关的技术）。它不仅仅提供了工程实现语言的灵活性，并让你能够完全地将工程切割开来。如果你打算在你的开发组或者公司之外实现你的工程的一部分，整洁的接口可以阻止任何与工程其它部分不适当的连接，同时你可以用任何语言来进行开发。你可以采取快速造型来实现所有的接口，稍后才对其中比较特别的部分进行优化。
6．设计时充分考虑异常情况
在C++中，异常控制并不像在Java中那样得到有力支持——这是Java在工程管理方面成功之处。在设计、代码编写和模块使用的时候往往会有一些错误，除非软件自身能够通过抛出一个异常来声明这些错误，否则你将会花费许多小时或月的时间来捕获这些问题。只有通过严谨的异常使用，你才能保证这些问题不会出其不意地让你的工程陷入困境。
7．简洁往往付出代价
虽然很难说服管理部门，但是“简洁”这个词是可维护性和复用性的同义词。不仅如此，一个简洁的程序让人感觉很好。但是因为我们确信软件工程是一种商业行为，目的是为了赚钱，而不是为了感觉，因此很难说简洁的程序比其他非简洁的程序更加有灵气地结合在一起。但是由于软件是一种能够赚钱的艺术实体，在美学和实用性之间必然会一场争论。
8．人与人之间的交流是一个瓶颈
这就是为什么小型的组队往往更加有生产力的原因。当一个工程像火焰一样失去控制的时候，将更多的程序员扔进火焰将使情况变得更糟。这也是为什么简短的小会议往往可以发挥作用而冗长的大型会议却做不到，还有为什么太深的管理机制会导致生疏的原因。参阅《人件》（早些时候提及过）一书了解更多的细节。
解决交流问题的最好办法是免费的：在一台废弃的计算机上安装一个Linux服务器，你可以在几分钟内完成这项工作，自动安装将包括一个Apache网页服务器。然后将你们所有的文档，从测试分析到用户文档，拷贝到服务器上，以便每个人都能够访问到最新的信息。你可以轻松地加入Java Servlets或者Perl脚本（http://www.perl.com/）或者Python(http://www.python.org/)来收集每一页的内容，然后用一个List服务器来向所有的成员发送公告。如果你想用camera-ready格式来提供文档，你可以用Adobe Acrobat格式来代替HTML格式。如果你的工程足够大的话，指定一名成员专门负责维护服务器是值得的。
9．制定一份计划（可以是任何类型的）
我曾经见过许多工程在没有签订任何合同（更别说一份计划）时已经有大量资金流动。哪怕是对于一个很小的工程，你也需要某种计划，甚至它可能只是被写在一个信封的背面或者只存在于主程序员的脑海中。当工程逐渐变大，你需要一个回顾的过程。一个典型的计划包括：分析阶段（包括你打算用程序解决什么问题以及程序将完成什么）、设计阶段（程序如何完成它的任务、程序实现的组成、分析阶段预定目标是否达到的测试使用信息以及发布、安装和培训等事项）。当新的信息被收集时，这些阶段将被重复。根据工程的大小，这些步骤将被缩小或者放大，但你必须像熟悉你的编程语言一样熟悉它们。
10．考虑外部帮助
一种放弃：我的公司提供培训和咨询服务，因此当然我感觉这是一个好主意。然而，如果你的公司内部有经验丰富的人可以担任你的工程的顾问，你可以不必向公司之外寻求帮助。这是一种以知识为基础的商业行为，生产力最低和最高的软件工人之间的生产力差别是很大的。如果你无法雇用那些最有生产力的工人，你可以通过培训提高他们的生产力，通过咨询和代码预排来改进你的工程的分析、设计和实现。对于顾问和客户来说，有一本优秀的书籍是Weinberg的《咨询的秘密》（出版信息：Dorset House,1986）
另一方面，我曾经见过一些工程中，使用外部的开发组队剥夺了内部的队伍的权利，该项目最后以花费更多的时间和资金收场。这将我们带到我的最后一个提示:
11.了解永远没有银弹（原文为：silver bullets,此处直译为银弹，估计引申含义和free lunch接近）的道理
这句谚语是由Fred Brooks发明的，对于今天仍然适用——尽管有许多“银弹”已经被发明出来了。统一建模语言（UML）就是这样一个例子：它当然是一个很好的通用词汇表和设计符号集，但是UML仅仅轻微地减少了方法学家之间的争论而已。永远不会有不劳而获的事情。你必须艰辛地计划你的对象、它们的接口和结构，然后跨越一道道障碍将工程变成成果。你必须清楚没有任何可以保证成功的方案可以依赖，同时牢记工程的失败的几率让自己更好的瞄准成功。
