另外一面
- 目的。主要的功能是什么？开发程序的原因是什么？
- 环境。程序运行在什么样的机器、硬件配置和操作系统上？
- 范围。输入的有效范围是什么？允许显示的合法范围是什么？
- 实现功能和使用的算法。精确地阐述它做了什么。
- 输入－输出格式。必须是确切和完整的。
- 操作指令。包括控制台及输出内容中正常和异常结束的行为。
- 选项。用户的功能选项有哪些？如何在选项之间进行挑选？
- 运行时间。在指定的配置下，解决特定规模问题所需要的时间？
- 精度和校验。期望结果的精确程度？如何进行精度的检测？
没有银弹——软件工程中的根本和次要问题
没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。所有软件活动包括根本任务——打造由抽象软件实体构成的复杂概念结构，次要任务——使用编程语言表达这些抽象实体，在空间和时间限制内将它们映射成机器语言。
再论《没有银弹》
Brooks在这篇文章里面再次讨论了很多潜在的银弹。因为自从《没有银弹》发表以后，遭到了大量的误解、批评和质疑，Brooks专门写了这篇文章来继续解释他的观点和回应批评。
首先一个可能的银弹是Harel提出的一种叫做Vanilla的框架，有助于程序的概念设计和图形化呈现，看上去确实直面软件工程开发的根本困难：复杂性和不可见性。Brooks甚至也赞同如果Vanilla框架得到发展应用，也许就是银弹。但是今天看来，20年过去了似乎Vanilla已经遭人遗忘。显然它并非软件开发的银弹。
另一个可能的银弹是定制软件包的开发。基本上今天的开源社区已经这样做了。大量的公共库被开发出来，确实提高了通用需求的开发效率。Brooks也承认，他低估了软件包客户化的程度和重要性。
面向对象编程，被称为“铜制子弹”。但是面向对象技术“不会加快首次或第二次的开发，产品族中第五个项目的开发才会异乎寻常的迅速”。不过经过20年再来看，面向对象虽然发展缓慢，但是的确已经统治了软件开发行业，称得上一颗“铜制子弹”。
大多数有丰富经验的程序员拥有自己的私人开发库，可以使他们使用大约30％的重用代码来开发软件。公司级别的重用能提供70％的重用代码量，它需要特殊的开发库和管理支持。公司级别的重用代码也意味着需要对项目中的变更进行统计和度量，从而提高重用的可信程度。
但是重用面临一个问题，就是重用所带来的好处，必须大于其代价，才得以实施。比如一个数学库函数，如果不重用，那么程序员自己需要学习大量的相关知识才能写得出来。而对于项目中的某个功能，与其花费很多功夫寻找重用的模块，可能程序员直接重新实现一次是更快捷的做法。
重用是一件说起来容易，做起来难的事情。它同时需要良好的设计和文档。即使我们看到了并不十分常见的优秀设计，但如果没有好的文档，我们也不会看到能重用的构件。
20年后的人月神话
今天，我比以往更加确信。概念完整性是产品质量的核心。拥有一位结构式是迈向概念完整性的最重要一步。这个原理不仅限于软件系统，它适用于所有的复杂事物。
如果要我用一个词语来概括人月神话，我想我会说“沟通代价”；如果可以有两个词，那就加上“概念完整性”。
20年后的人月神话有些结论得到验证，有些情况已经变化，下面是这些情况的简单概括：
- 第二系统定律得到验证：开发第二个系统总是因为盲目的功能导致易用性、甚至是可用性的灾难。
- 图形界面的成功
- 瀑布模型被证明是错的了，因为没有构建舍弃原型。事实上增量开发与快速迭代才是理想的开发方式。
- 增量开发和快速原型，渐进地精华，让软件像生物进化那样逐渐演化成更为复杂的结构，演化出更多的功能。
- 信息隐藏：Parnas是正确的，我是错误的。20年前关于信息隐藏的两大观念，其一是Brooks主张的，所有的程序员应该了解所有的材料。而Parnas则认为代码模块应该采用定义良好的接口来封装，这些模块内部结构应该是程序员的私有财产。Brooks承认，Parnas所主张的方案确实更符合实际。
- 对人月神话实际研究发现，向进度落后的项目中添加人手会增加项目的成本，但是不一定会使项目更加落后。如果在项目早期添加额外的人比在后期添加额外的人更安全些。
- 人就是一切。这一点可以从《人件：高生产率的项目和团队》可以见出。
- 放弃权利的力量——公司通过将权利下放到具体的团队，事实上使得组织机构变得更加“融洽和繁荣”。
- 最令人惊讶的新事物——数百万的计算机
- 使用塑料包装的成品软件包作为构建：成熟的模块和对象组合提升了软件复用的层次。