在《人月神话》里看到引用的一篇论文,《没有银弹：软件工程的本质性与附属性工作》（英语：No Silver Bullet—Essence and Accidents of Software Engineering）, 这是IDM工程师的一篇关于软件工程的经典论文. (论文链接: http://www.cs.unc.edu/techreports/86-020.pdf)

该论文中强调由于软件的复杂性本质，而使真正的"银弹"并不存在；所谓的"没有银弹"是指没有任何一项技术或方法可使软件工程的生产力在十年内提高十倍。好了, 看看这篇论文摘要.

所有软件创作都包括了本质性工作（essential task）和附属性工作（accidental task）。前者是去创造出一种由抽象的软件实体所组成的复杂概念结构，后者则是用编程语言来表现这些抽象的实体，并在某些空间和速度的限制之下，将程序对应至机器语言。

现在，若跟本质性的工作相比，软件工程人员所做的事，还有多少算是花在附属性的工作上呢？除非附属性工作要耗费的心力超过全部工作的9/10，否则就算是将所有的附属性工作降至零，也无法将整个开发工作的轻松程度提升一个数量级。

因此，似乎是时候解决软件任务的本质性部分了，这部分涉及形成非常复杂的抽象概念结构。我建议:

- 开拓大众市场，避免构建可以购买的东西。

- 在建立软件需求时，将快速原型(rapid prototyping)作为计划迭代的一部分。

- 有组织地增长软件，为系统增加越来越多的功能运行，使用和测试。

- 确定并培养新一代的优秀概念设计师。

这篇文章的主要观点是: 把软件一分为二, 软件 = 本质性工作 + 附属性工作. 并且附属性工作的复杂性已经大大降低, 如今的程序员大部分时间都花在解决本质性工作.

我的观点

我觉得这篇论文有一定的道理, 大多数程序员, 至少就我而言, 编写代码的时间占用很少, 大部分时间都在思考解决问题的方式. 一旦处理问题的逻辑清晰下来, 接下来编码实现的速度是很快. 但是这篇论文并没有抓住软件开发的重点: 文章把软件开发的焦点集中在生产力上，也就是软件每单位的时间投入成本能得到多少输出效果. 比起关注生产力, 我更认同Caper Jones的观点: "Focus on quality rather than quantity and program will follow." (把重点放在质量上，生产力将随之而来).

从个人在公司开发软件的经验, 我们过去两三个月以及更多的时间, 都在修复旧的bug和优化原先的功能缺陷. 试想如果每个软件开发者都是认真负责的, 那整个项目的生产力会在一个新的台阶上. 正因为我们的代码库里存在太多不负责的代码, 这些代码大多并不是--编程技术上的bug(容易发现, 并且容易修正), 而是--实现上的敷衍(不容易发现, 并且不容易修正). 如果在编程时只是为了完成任务, 并没有为自己的代码抱有认真负责的态度, 那么这样的代码将在后续的维护和迭代升级中造成灾难.

引用王垠在《怎样尊重一个程序员》的一段话

如果你明白我在说什么，从今天起就对自己的代码负起责任来，不要再让其它人修补自己的BUG，不要再修补其他人的BUG

当我持有这样的观点时, 我就开始觉得《人月神话》这本书没有读下去的必要性了, 因为我们关注软件开发的侧重点截然不同.