在软件社区中，Ward Cunningham享有思想源泉的美誉。他发明了CRC Cards，这是改进对象发现的一种技术。为了促进软件模式的发现和编档，他发明了世界上第一个wiki，一种基于web的协同编写工具。最近，许多极限编程（Extreme Programming）技术背后的主要灵感也被归功于Cunningham。
在2003年9月23日于丹麦Aarhus召开的JDOO大会上，Bill Venners遇到了Ward Cunningham。在这次访谈中，Cunningham深刻剖析了使用wiki协同探索和极限编程的几个方面。
在第I部分“使用Wiki探索”中，Cunningham讨论了使用wiki协同探索以及wiki作者和读者之间的权衡。
在第II部分，Cunningham讨论了他如何把wiki设计成这样一种模型：集体代码所有权、以所有权而自豪的集体激励以及通过消除犯错的代价来解决纷争。
在第III部分中，Cunningham讨论了变更成本曲线的扁平化、预测未来的问题以及像艺术家手中的泥巴那样塑造程序。
第I部分使用Wiki进行探索
为什么需要Wiki？
Bill Venners：您发明wiki的最初目的是什么？
Ward Cunningham：我创建wiki要完成几件事。第一个wiki的初衷是要建立一种环境，我们能够交流彼此的经验，从而发现编程的模式语言。我以前曾经使用过HyperCard组，它基本上也是为了类似的目标。我知道人们喜欢使用那种HyperCard组来阅读和创作，但它是单用户的。当开始PLoP（编程模式语言）系列讨论会的时候，我们认识到我们真正想要做的是开始编写一部新的作品，我认为我需要使用HyperCard组，并希望能找到一种应用于web的等价物。
对于wiki，我还有更多通用的目标。首先，人们常说“人人喜欢讲话”，我认为这里面有一种令人信服的人类本性。在创建wiki时，我希望激发每个人喜欢讲故事的天性。其次，也许是最重要的一点，我希望不经常创作的人们会发现创作非常轻松，这样就有机会发现创作的结构和方法。
Bill Venners：wiki如何使创作变得轻松？
Ward Cunningham：不熟悉写作的某个人可能有一个想法，这个想法值得写成一段。他们本来可以为杂志写一篇评论，但是一段文字太短了。为了给杂志撰写文章，他们不得不介绍一下背景，讲述某些重要的东西，而且要以多数人都能理解的方式讲述，然后结束文章。太复杂了，多数人都不愿意花费那么多的精力。
但是如果您正在阅读别人的作品，并想到“是的，但是还有一点”可以放在一段中这样说，“啊，不错，但实际上还有……”在wiki上有很多这种类似于“对，但是……”的对比想法。讨论组也作了同样的事情，但是在讨论组中这些对比都丢失了。
Bill Venners：为何在讨论组中丢失了？
Ward Cunningham：因为没有上下文，无法持续下去。讨论组往往反复围绕着同一个话题，但是人们忘记了以前说过什么。我认为，常见问题解答（FAQ）的发明就是针对这个问题的。很多时候，读一读FAQ要比参加讨论组更有意义。在一开始做wiki的时候，有一个系统叫FAQ-O-Matic，它和wiki的想法一样，只不过其真正的目的是制作FAQ。我看到它的时候就想“哦，英雄所见略同”。不过我接下来又想，“不，我更喜欢面向文档的形式而不是问答形式。”在我们的作品中想要创建的模式是某种类似FAQ的东西，但应该不止如此。现在，wiki上可能有10,000到15,000种模式，25,000页文档。
Bill Venners：您认为wiki适合做什么？wiki的高明之处在哪里？
Ward Cunningham：如果您试图回答一个不容易阐述的问题，事先不了解某种应该知道的自然结构，wiki会非常有用。对于像“项目进展如何”之类的问题，我们可以设计一个数据库。但是数据库中要放哪些字段还要归结到对项目进展问题什么是重要的。关于项目的哪方面重要这些资料是不可预见的。
Wiki页面的格式非常自由。在整个wiki中有一个超文本结构，但是在一个给定的页面上，在自然语言灵活性的许可范围之内，您可以讲任何想要述说的东西。因此，wiki是跟踪项目进展状态的一种良好方式。比方说，您可以把我的模式作品看成是一个长期进行的项目。我们不知道终点在那里，但是我们希望在进展中发现它。
此外，wiki也非常适合于想要把控制权交给系统用户的环境。在wiki中并没有多少何人何时可以做何事的逻辑，因为wiki并不真正理解您在做什么。它只是为您保留页面。关于什么是适当的用法什么是不好的用法，已经建立了大量的惯例，但这些都存在于用户的头脑中，而不是在应用程序的业务逻辑中。如果您有一个可靠的团体，不谋求通过计算机强制某种行为，wiki就可以很好地工作。比如，有人曾经问我wiki是否适用于协同环境。我认为某些公司对它们的雇员完全具备这种信赖，某些公司则没有。不信赖雇员的公司可以根据某些需要维护一个web站点而不是wiki。
把握大局
Bill Venners：读者如何把握wiki上的总体内容？
Ward Cunningham：首先要理解，因为我们使wiki更方便作者，实际上就增加了读者使用的难度。里边有某种组织方式，这种组织方式还可以改进，但它不是组织严密的。因此读者就会感到仿佛是在茫茫的一片信息片段中搜寻。偶然发现一段很好的信息，于是就想，“好极了，为什么没有人哪怕只是把那些好的片段作一个清单，我就不用再搜索其他的部分了。”换句话说，“为何没有人组织一下，让我迅速找到问题的答案？”早晚他们的想法会得到实现，“哎呀，行了！”他们花了一个月或者两个月查找所关心的东西，然后做一个页面，wiki组织成什么样子由他们自己承担。
我不是一个分类的痴迷者。如果感兴趣的事物不符合需求或者不是预期的，定义一个有用的分类方案非常困难。不过有些人认为每个页面都应该带有分类。他们带着一个分类方案，根据页面的名称，为wiki建立分类结构。这些注重分类的人负责维护它。如果某人创作了一个不能归类的页面，其他的人就会说，“哦，这应该归为wiki保留页面或者设计模式。”
Bill Venners：如何把一个页面归类为wiki保留页？
Ward Cunningham：只需对一个叫做WikiMaintenanceCategory的页面进行引用。单击该链接时，就会转到那一页，对这种分类进行解释以及为何有这一类。因此把页面归到某一类，习惯上是增加到该类别描述页的链接。这样标记了该页。如果要了解这一类是什么，可以沿着链接到类别描述页。如果要看看这一类中有什么页面，可以搜索引用该类别页的所有页面。
Bill Venners：我猜想搜索也许是研究新wiki的一种方式。从一定意义上讲，wiki类似于一种小型的internet。 一切都分散在各处。如何发现正在寻找的内容呢？我可以从搜索关键字开始。
Ward Cunningham：是的。任何名称以“Category”结尾的wiki页都是一个值得搜索的条目。可以通过Google搜索小说，但是如果有人不把作品标记为小说，就找不到它。分类系统是一组页面，解释分类的基本原理，可以读读这些页面。它们使用了名称空间的一小部分——所有这些词都以“Category”结束——并建立了这些页面涉及其他页面分类的实例。非常棒。还在发展中。如果我要做一个解决方案，可能会非常简单，甚至同样好。我最喜欢的一点是，有一个非常积极的社区在管理这些分类。有时他们把分类搞错了，但很快就会纠正过来。
Wiki中的时间要素
Bill Venners：您所说的有点让我想起“自由讨论”。您把一些人集合起来充实那些您还不完全清楚的事物。
Ward Cunningham：Wiki有点像“自由讨论”，尽管不是交互式的。您可以做10分钟的自由讨论，用30分钟分析自由讨论的成果，然后在45分钟之内完成某件事。Wiki的脚步要慢一些。您可以就某个观点写一个页面，或者就很多想法写一个页面。然后在一周之内回来看看页面上有什么进展。但是如果在15分钟之内回来，不会发生太多的变化。Wiki上的事情是以天或者周为周期的，因为人们往往每天或每周浏览一次。
Wiki中有一个有趣的时间特性。读新闻组或者邮件列表时，会有一种感觉，当前就是您在列表中的位置。我不希望wiki中有一个时间表。当在读wiki上的某些内容时，我不希望时间会影响您，不论它是一年前写的还是一天或者一分钟前写的。这意味着我们需要通过某种方式得到上下文。
如果您正在编写一个页面，那个页面必然和其他某个页面有关。因此所要做的就是，在一个段落中说明其他页面中哪一些是关于这个上下文的。人们逐渐熟悉这些页面的名称。他们遇到一个新的页面，阅读包含对上下文页面链接的段落。如果已经度过这些页，就继续读下去。如果不知道这些页，他们就会说，“哦，这一页没有什么意思。我还得读一读其他的页。”这样如果您了解上下文的话，就不必再去看了。但是如果不了解上下文，您可以去看一看。上下文不会变。
Bill Venners：听起来似乎您必须了解wiki站点。过一段时间后您就会熟悉它了。一开始可能会令人感到困惑，也没有多少提示，您进来发现到处都是这样的内容，但不一定是根据读者的需要组织的。
Ward Cunningham：对，wiki总是在不断地组织中。每花费一个小时组织，都要花费另外两个小时来增加新的材料。因此wiki的总是处于半组织化状态。
Wiki 和可读性
Bill Venners：我确实非常喜欢wiki的思想，但是我发现阅读许多wiki页非常困难。可读性的问题是我一直没有在Artima.com上增加wiki的主要原因。Artima.com也是一种基于web的协作文档，但是更加结构化。在wiki中没有专职编辑为读者组织材料。所有的页面都是协作性的。结构是协作性的。编辑是协作性的。从wiki的协作性中有什么足以抵消可读性的损失？
Ward Cunningham：作为wiki读者，您能够获得以前没有发言的那些人的观点。听我们发言的人对于怎样编写和发布计算机程序有直觉的想法。我们这一行在发表过程中对传统保留了某些尊重。比如，如果您想为一本科学杂志投稿，应该经过同行评审。同行评审的一部分是你应该熟悉所有其他作品。而其他作品可能纠缠进某些细枝末节。关于编程的作品有时并不符合程序员的实际感触。有了wiki，没有时间学习写作并在杂志上开辟专栏的实践程序员，就有机会讲出那些对于他们来说是重要的事情。Wiki提供了一个不同的视角。事实上，您可以分辨出一个人是在wiki上根据自己的经验创作，还是转述刚刚读到的东西。
Bill Venners：那么您怎么分辨呢？
Ward Cunningham：您可以根据他们谈论事情的方式来区分，比如“Mary Ann就是做不好这一部分。”这不符合科学传统。如果有人引述某位作者的话，“某某怎么说，你这家伙怎么听不明白”，有人在赞美他所读的书。另一方面，如果有人说，“您知道，在以前的三个项目中我们都尝试过，但一次也没成功，我们只能用别的办法摆平它。”有个家伙解决了这个问题，他正在跟我谈一些深刻的问题。如何解释要靠我自己。这只是他的经验。然后您可能还会看到其他几段文字，“是的，我也遇到过，我用这种方法搞定了。”那么现在就有两种方法了。突然之间，您开始与解决了软件问题的人交流了，而不是和谈论解决软件问题的人交流，这有很大的不同。
第II部分代码和文本集体所有权
集体的代码和文本
Bill Venners：极限编程（XP）的集体代码所有权特点让我想到了wiki，在wiki中，每个人对所有一切负责。
Ward Cunningham：这样做完全是有意的。在设计wiki前的几个月中，我们有过一次争论。我认为Kent Beck和我站在一边。坚信主流软件工程教条的那些人站在另一边。我们说“集体代码所有权很好。”他们则说“太荒谬了。没有职责划分，而没有责任就决不会有质量。让他们避免制造缺陷，就必须把缺陷和某个人挂钩。”我说，“完全不对。”
我设计wiki的决定，很大程度上受到建立一种协同过程模型的渴望所启发，我认为在大型代码库中应该有这种协作。我希望wiki能够模拟这种情况。比方说在一堆代码中有一个问题。您知道怎么解决问题，但是解决需要涉及到大量模块。重构需要大量艰苦的工作，如果要同每个最初的作者协商就更加困难。你只是希望改正问题。
困难在于代码可能是按层次结构组织的，但是解决方案可以从多方面来考虑，而不止是某种层次结构。因此当您在某一方面发现一种贯穿整个层次结构的解决办法时，您只能随着解决方案的要求，在适当的地方加入解决方案。我们经常发现自己处于这样一种境地，人们了解这个程序，但是他们不能将这些知识应用于程序。为什么？因为知识的发展和在拥有这些知识之前做出的某些组织决策相冲突。换句话说，程序抗拒知识的积累。
Bill Venners：抗拒？
Ward Cunningham：程序对某种类型的知识有抵抗力——没有预计到的知识——因为很难在一开始就设立的结构内表达这些知识。很难把不符合这种结构的任何东西加进去。
Wiki中也有一点对预料之外思想的抗拒，但这种抗拒主要在人们的实践中。Wiki中写进去的东西越多，对自身权利的要求越严格，但是如果有人要修改而且到第25页去修改，他们就可以去25页。
比如，在wiki中，发生的某个过程是页面从讨论发展成短文。许多人愿意阅读讨论。那些每天访问wiki的人希望看看昨天又说了什么，因此需要按时间组织的页面。但是对学习而言，投稿先后顺序并不是一种很好的组织原则。因此页面总是保持某种讨论之中的感觉，直到这个讨论结束。后来，有人又回来阅读了这些讨论，把您可能称之为线性模式的页面重新组织成文档模式的页面。
如果在注解之间转来转去，而且有许多类似的彼此相邻的注解，您经常会发现可以去掉一大半篇幅。因为只要位置适当，一句话可能就说明白了。在Ward的wiki上，这个过程被称为“重构（refactoring）”，就像我们在软件中那样称呼这个过程。Ward的wiki是关于软件的，其中有许多从事软件的人，因此称为重构。在其他地方可能就会称为“编辑”了。在Ward的wiki上，重构是一个持续的过程。设想如果某些地方被证明不很合适，就要再次进行重构。一切都是重构的目标。这也是我们愿意在软件中所看到的。
软件的优势是它有明确的解释。因为软件是为机器编写的，我们可以依靠精确的解释编写测试。在重构程序时，我们可以测试没有破坏或者丢失的任何东西。但wiki是为人类编写的，没有精确的解释。我可以说，“哎呀，我可以把这个句子放在这儿，并砍掉一半，因为在这个上下文中很容易理解。”但是我可能错了。对于我容易理解，但可能对其他人很难，我也没法做测试。因此在重构过程中，我们可能会丢失wiki上的某些信息。Wiki像一个信息漏桶。它每天都在丢失信息。但是有更多的信息加进来，因此净结果是正的。即使丢失了某些东西，wiki总是比昨天有更多的内容。
高质量代码的集体激励
Bill Venners：从您的描述中我了解了集体代码所有权的好处。但代价是什么？集体代码所有权的缺陷是什么？
Ward Cunningham：我相信有一些缺陷，但是现在还没有想到。
Bill Venners：所有权的自豪感又如何？人类适应集体自豪感吗？在您自己创建什么时，总是希望把它做好。
Ward Cunningham：我认为集体所有权实际上更好一些。是的，我对自己所做的事情感到自豪。对于我而言，自豪感是一种激励。通过集体所有权，我们基本上建立了一种小型的社区，训练他们自我肯定所做的工作。但如果归我所有，人们就会说，“那是Ward的模块，我不想看Ward的模块。”如果必须调用Ward的模块，他们可能会喜欢该模块的API。我的模块缺陷率很低也许会给他们留下印象。不过他们可能会说，“他的模块很简单。他有一个容易编写的模块，这就是为何他的缺陷率这么低。”他们不会知道真正的原因。
当人们使用我提供的材料时，他们会感觉到是否容易使用。所谓使用材料，我是指拿来代码调整，以便做更多一点工作或者稍微改变其功能——这些代码应该做的任何事情。当人们使用代码时，他们会看到我努力完成的一些事情，否则的话他们永远也不会注意到。不需要迫使他们说“Ward你很了不起”，但有时候他们会说，“Ward你很了不起。”这就满足了我的自负感。所有权的自豪感？的确如此。
现在，不需要在每一行上写上我的名字。事实上，这证明如果它确实很好，可能是因为他们做得好，而不是我。我可能只是做了一个计划，然后他们完成了而且完成得很好。我可能会受到不应得到的荣誉，不过他们也可能把赞誉送给别人。一个想法来自谁，荣誉应归谁，这种观点是弹性的。但我认为人们在知道谁参与其中的时候，可以很好地解决这种弹性，承认每个人的贡献。通过集体所有权，我们建立了一种社会环境，通过源代码语句中迸发的智慧可以了解一个人。
Bill Venners：集体所有代码的这种特点为何不能出现在wiki页面上，wiki页面上的内容有时候显得有点乱？
Ward Cunningham：我肯定也会这样。
Bill Venners：您刚才谈到某一行代码是谁编写的并不总是很明显。对于wiki页面也是如此。谁写了某一行文本也并不总是很明显的。有时候一个人在wiki页面上写了一些东西，“我有这样的经验”，而作为读者我并不知道这个“我”到底是谁。集体代码所有权和集体文本所有权相比有什么不同，您刚才只谈到了代码而没有涉及文本？
Ward Cunningham：我认为不可预料的代码是很常见的。代码可能能够工作，但如何工作本质上是秘密的，不可能阅读。事实上，这也可能是一种常见情况。因此混乱可能不够确切，应该是不可读。我有与他人长期结对编程的经验，在读到他们的代码时，甚至认为是自己的代码。但在wiki上还没有出现这种情况，我读到某人的文字而认为是自己写的。这可能是因为代码具有更高的组织性，但我认为更可能是因为代码交流的范围更狭窄。代码交流的范围仅限于某种过程的计算机化，而谈话的最佳方式是相当广泛的。这样就会导致和英语相比，代码会更快地具有稳定的组织性。
解决纷争
Bill Venners：在“Extreme Programming Explained”一书中， Kent Beck写道，“集体所有权增强了在项目中对个人能力的认知。您不会永远钉住别人的蠢事不放。您在途中发现了某些东西，然后把它排除掉。”对于什么是蠢事如果不同人的看法互相矛盾时该怎么办？所谓蠢事不是一种主观的评价吗？
Ward Cunningham：啊，我决不会这样说。当我认识到不需要赢得每一次争论的时候，这是我编程生涯中的一个转折点。我正在和别人讨论代码，我说“我认为最好的做法是A”，他们则说“我认为最好用B”。我说“不，应该是A”，他们则坚持说“我们想用B”。当我能够这样回答的时候，对我而言这是一个转折点：“好吧，用B办法。如果我错了这样就不会损害我们。如果我对了，而您用B办法也不会造成多少损害，因为我们可以改正错误。让我们看看这样做是否错了。”
我们不要把自己看成非常幸运的预言者，要求自己预测未来。最好是建立一种环境，这样您就能够试一试B并看看发生什么。现在证明争吵通常是无益的。无论谁编程，都可以自由选择编程的方式，这样就足够了。当然有时候也可能会证明争论是有用的。我们正在做别的事情，看了看说，“您知道，用在那里并不合适，因为B确实不符合。”而这个问题可能是我在宣传A方法时正好考虑到的，也可能不是。它可能是开发人员在方法B的上下文中硬塞进去的。但有时候您了解这些缺陷或者难以改进的地方。于是开发人员说，“你知道，这些代码令我感觉不舒服。”我说“好吧，我可以解决这个问题”。他们问道“您行吗？”我说，“当然，我可以解决这个问题。您做了B，我就使用B。”然后我就可以开始处理它，只要可能就尽量使用B。但是因为承担了职责，我就有机会使它实现需要的功能。
Bill Venners：您是说再回到A。
Ward Cunningham：如果需要的话。
Bill Venners：也可能是到C。
Ward Cunningham：通常会变成C。对于我们双方这都是一种学习的经历。如果没有这种经历，我们就都没有学到什么。Ward赢了，其他人输了。或者相反。这和一场战争差不多。为什么不说，“好吧，让我们编码看看怎么样。如果不行的话我们再改变。”
我无法告诉你我花费了多少时间担心无关紧要的决策。如果能够做一项决策，然后看看结果如何，当然会大大减少这种担忧，但是这意味着您必须建立一种环境，当确实出问题时可以修正。如果某些事情确实出了问题，不会浪费您和您的客户过多的成本。这不是一种可笑的花费。如果您处于不能承受错误的情况下，就很难做正确的事情。因此如果尝试做正确的事情，正确的事情可以抵消犯错误所造成的代价，要远比猜测什么是正确的好。
比如，在一个项目中我们通过经常升级抵消了错误成本。我们是通过建立一个相当精细的数据库模式演化机制实现的。。我们曾经每周发布一次，每周都修改模式。我们可以为不同的客户根据不同的要求对模式作不同的修改，把这一切结合起来最终得到正确的结果。因为我们每周都在做，大约六周或八周以后，我们就确信我们可以完成它了。我们从没有担心过。多数人都说，“无论做什么，千万不要做模式演化除非你已经做了。”但在项目结束的时候，他们说，“天哪，我们真的做到了。”因此在从来没有做过之前，他们说，“只要我们去做，就让我们做完它吧。”他们做了一个巨型项目，以前从未有这样的经验。你猜怎么样？他们错了。相反，我们每周都在做。每周做一点。我们确实从中受益了。我们永远不会害怕它。它也从来没有出现问题。
因此我们不是通过说“我们要做的工作性质就是这样”，从而通过抹去问题来解决问题。要是这么简单的话才是真的奇怪了。实际上更多的是提问的方法，“您希望擅长什么？”，如果您希望擅长它，就找出一种方法来每天应用它。如果每天都要应用，那么就只能熟练掌握了。因此，选择您希望擅长什么。您应该擅长您所害怕的东西，这样您就不会再害怕它了。
第III部分塑造程序
变更的成本
Bill Venners：在“Extreme Programming Explained”一书中，Kent Beck写道，“软件工程中一个普遍的假设是程序修改的成本随着时间呈指数级增长。”并建议说，“通过技术和编程实践的结合，有可能得到一条方向相反的曲线。”怎么能够实现变更成本曲线的扁平化呢？
Ward Cunningham：传统上来说，变更成本曲线告诉我们，早发现变更的需要与晚发现这种需要相比，进行变更所花费的代价越小。我批判了这种曲线，因为根据这种理论，我们差不多可以故意犯错，然后在实践中改正错误，这样有助于减少以后变更的成本。
我们认为，任何变更的决定因素不是何时进行变更，而是需要做多少思考。如果我们每周做一次变更，而理解我们的真正需要花费了两天，那么做这种变更就需要两天。如果我们每21周变更一次，理解我们的真正需要也花费两天时间，那么这个变更也用了两天。
在每周一次的变更中，我们可能要写20条语句。在21周变更一次时，我们可能需要写20条语句并修改4条语句。但是如果您习惯于变更，修改4条语句也花不了多少时间。只需要找到那些语句并修改它，可能只需要1分钟。
因此理解变更的需要是决定性因素。编程实现变更并不重要。只要我们理解了变更，我们就可以编程实现，或早或迟。修改代码的实际成本并不在编程中占有主导地位。主要的成本是理解所花费的时间，这就给出了一条趋向平缓的变更成本曲线。
许多人害怕变更，是因为尽管在编写的时候还理解代码，但这种理解很快就消失了。他们对你说，“我们为这些语句费尽了心血，无论如何不要改变这些语句！”他们并不想回到原来的代码，因为重新理解太费劲了。因此使变更成本曲线扁平的另一种方法，即以后变更的成本不会比现在更大，就是确定人们必须能够看到他们将要改变什么并理解它。因此，当你在编写代码时，你就会更多地为将要阅读代码的人编写，而不是为运行它的机器编写。
同样，你也不愿意编写大量的注释，告诉别人如何进行他们所需要的修改，因为您并不知道他们要进行何种修改。最好抱有这样一种观点，您不能帮助将来的程序员进行修改。您所能做到的就是使他们容易理解您努力去做的事。如果您非常小心，避免做太多的事情，这样最有助于他们理解您的努力。您试图完成的功能越多，将来的程序员要理解您的代码就越困难。
比方说，如果您明显地忽略了一种情形，以后的程序员需要解决它，他们打开代码发现您显然是忽略了这种情形。这意味着他们可以自由实现需要的任何功能。但是如果您试图应付这种情形，他们来了首先要确定哪里不工作。他们将看到您试图解决这种情况，因此他们首先要尝试理解您在做什么。一旦理解了您要做什么，他们就可以指出如何修改以实现需要的功能。他们更愿意接手的时候发现您甚至没有考虑到这一点。也许您想到了，但完全没有对此编程。
对未来的预测
Bill Venners：每个人都同意预测未来是很困难的，但预测总是这么糟吗？
Ward Cunningham：在科学中预言未来很简单。科学建立在对物理系统行为研究的基础上，被证明具有惊人的可预言性——可能天气除外。我们已经能够向太空发射火箭并使它沿轨道运行，这是预测的一个范例。但是当开始谈及对未来的期望时，我们可能有某些直觉，这些直觉也许是对的，但不会总是对的。我们必须考虑到不正确的情况。
当一个新的需求出现时，我们看了看说，“好的，这不难。这个程序就是为它而作的。”我们在程序中加入一些代码，然后就成了——我喜欢这样。我讨厌这种情况，新需求的出现不能很好地满足，仿佛程序的设计就是为了和需求作对。这种情况下，我们有大量的工作要做。但是这项工作的性质要求首先修改程序使它更容易适应新的需求，然后把新的需求包含进来就很容易了。换句话说，不是为新的需求在并不适合这种需求的结构上打补丁，而是全力以赴做艰难的任务修改结构，使它能够很容易实现这种需求。打补丁的办法意味着，后来者不但要理解并非为这种需求设计的系统，还要理解试图弥补但不改变系统的那些补丁。最好是修改系统以便很容易适应新的特性。
有人也许会说，“为什么不向前看一看，了解我们必须做到的所有工作呢？为什么不从一开始就把系统设计成使所有工作更方便呢？”如果您能够实现这样一个系统，那真是太好了。正是这样，人们一次又一次地试图设计系统使明天的工作更容易。但是当明天到来时，却发现他们并没有很好地理解明天的工作，实际上他们使明天的工作更难了。
意外的体系结构
Bill Venners：为了批驳变更成本曲线，您发现了一种方法可以在项目的整个生命期中进行变更。这就使得对将来的计划不那么重要了，因为可以在以后真正需要展开的时候进行变更。整个体系结构仅仅是在每次只关注一小步的过程中逐渐浮现出来的吗？
Ward Cunningham：我喜欢塑造程序这种说法，就象艺术家塑造一团泥巴一样。艺术家想做一个雕塑，但是在开始雕塑之前，她只是把泥巴揉来揉去。她开始逐渐塑造成形，并看到泥巴要成为什么样子。揉捏得越多，泥巴就越像她希望的样子，最终变得完全符合她的想法。
一个开发小组用了数月编写一段代码。最初，他们做了一段代码，有点僵硬。代码很短，但仍然有点僵硬。他们搅动这些代码，代码稍微变软了点。在上面提到的一个项目[第II部分]中，我们向数据库增加了模式演化功能。它软化了程序，变更容易多了。每次变更模式时，我们都作一点改进。程序员和代码——作为一个整体——都软化了。我们塑造程序并保持它的柔软性。
在项目结束时您已经完成了需要做的所有事情——有人为之付钱的所有功能——您看了看代码问道，“这一堆东西中的核心是什么呢？这是怎么完成的？我们日复一日地编写程序，它是怎么结束的呢？”通常程序的结束都是令人惊诧的。您会说，“这是一种优美的结构。”那么体系结构又从何而来呢？
在这里，体系结构意味着我们处理不同需求的系统化方式。当我们根据需要塑造程序时，体系结构使我们能够发现进展到哪里了。融入程序的是一个系统，包括我们所做的每一个小决策——正确的小决策，错误但改正了的小决策。从某种意义上讲我们得到的这个体系结构并没有经过尝试。在其他决策上下文中的所有决策凝结成了一种体系结构。