为了更新和改善程序，需要更新思考问题的方法。它不只是“我们如何让程序工作”，而是“我们如何让程序工作并且使它容易改变”。这里就有一个新问题：当我们只是试图让程序工作时，我们可以假设开发组是稳定的（总之，我们可以希望这样），但是，如果我们正在考虑程序的整个生命期，就必须假设开发组成员会改变。这意味着，新组员必须以某种方式学习原程序的要点，并与老组员互相通讯（也许通过对话）。这样，该程序就需要某种形式的设计文档。 ? ? ?因为只想让程序工作，文档并不是必需的，所以还没有像由程序设计语言强加于程序那样的、强加于创建文档的规则。这样，如果要求文档满足特定的需要，就必须对文档强加外部原则。文档是否“工作”，这很难确定（并且需要在程序一生中验证），因此，对外部原则“最好”形式的争论.比对“最好”程序设计语言的争论更激烈。决定外部原则时，头脑中的重要问题是“我准备解决什么问题”。问题的根本就是上面所说的“我们如何让它工作和使它容易改变”。然而，这个问题常常有多种解释：它变成了“我如何才能与FoobleBlah文档规范说明一致，以使政府会为此给我拨款”。这样，外部原则的目的是为了建立文档，而不是为了设计好的、可维护的程序。文档竟然变得比程序本身更重要了。
被问到未来一般和特殊的计算的方向时，我会从这样的问题开始：哪种解花费较少？假设这个解满足需要，价格的不同足以使程序员放弃他当前做事情的习惯方式吗？如果他的方法包括存储在项目分析和设计过程中所创建的每个文档，并且包括当项目进化时维护这些文档，那么当项目更新时，他的系统将花费很大，但是它能使新组员容易理解（假设没有那么多的使人害怕阅读的文档）。这样创建和维护方法的花费会和它打算替代方法的花费一样多。外部结构系列的另一个极端是最小化方法。为完成设计而进行足够的分析，然后丢掉它们，使得程序员不再花时间和钱去维护它；为开始编码而做足够的设计，然后丢掉这个设计，使得程序员不再花时间和钱去维护这些文档；然后使得代码是一流的和清晰的，代码中只需要最少的注释。为了使新组员快速参与项目，代码连同注释就足够了。因为在所有这些乏味的文档上，新组员只需花费很少的时间（总之，没有人真地理解它们），所以他能较快地参与工作。即便不维护文档，丢掉文档也不是最好的办法，因为这毕竟是程序员所做的有效工作。某些形式的文档通常是必须的（参看本章后面的描述）。
1.通讯
对于较大的项目，期望代码像文档一样充分是不合理的，尽管我们在实际中常常这样期望。但是，代码包含了我们实际上希望外部原则所产生的事物的本质：通讯。我们只是希望能与改进这个程序的新组员通讯就足够了。但是，我们还想使花费在外部原则上的钱最少，因为最终人们只为这个程序所提供的服务付钱，而不是为它后面的设计文档付钱。为了真正有用，外部原则应当做比只产生文档更多的事情—它应当是项目组成员在创建设计时为了讨论问题而采用的通讯方法。理想的外部原则目标是使关于程序分析和设计的通讯更容易。这对于现在为这个程序而工作的人们和将来为这个程序而工作的人们是有帮助的。中心问题不只是为了能通讯而为了产生好的设计。
人们（特别是程序员）被计算机吸引（由于机器为他们做工作），出于经济原因，要求开发者为机器做大量工作的外部原则似乎从一开始就注定要失败。成功的方法（也就是人们习惯的方法）有两个重要的特征：
*1)它帮助人们进行分析和设计。这就是，用这种方法比用别的方法对分析和设计中的思考和通讯要容易得多。目前的效率和采用这种方法后的效率应当明显不同。否则，人们可能还留在原地。还有，它的使用必须足够简单，不需用手册。当程序员正在解决问题时，要考虑简单性，而不管他适用于符号还是技术。
*2)没有短期回报，就不会加强投资。在通向目标的可见的进展中，没有短期回报，人们就不会感到采用一种方法能使效率提高，就会回避它。不能把这个进展误认为是从一种中间形式到另一种中间形式的变换。程序员可以看到他的类，连同类之间互相发送的消息一起出现。为某人创造一种方法，就像武断的约束，因为它是简单的心理状态：人们希望感到他们正在做创造性的工作，如果某种方法妨碍他们而不是帮助他们飞快地接近目标，他们将设法绕过这种方法。