让我告诉你一个故事：当我在大学的时候，我学习了一门高级的面向对象的程序设计课程。我以前从未接触过这门知识，而且这门课是用一种非常特殊的方式教授的。在第一天，教授给我们分配了一个贯穿T的任务。他整整四周的课程。

我们非常兴奋，因为这是写一个游戏。一个老式的字符输入冒险游戏，类似于风格。我们分成3组，来到教授的拥挤的小屋。教授给了我们一张纸，上面有一些注释。我们几乎跑来跑去。

哦，我差点忘了。两个星期后，我会对游戏内容做一些重大的修改。你应该继续根据修改来解释开发。

我把这个故事告诉了许多软件开发团队，包括一些软件产品创建者，他们的反应几乎是一样的：

问题是，教授并没有告诉他，他会做出什么样的修改。只是说，两周后，事情就会发生变化。

这就是我们所做的。我想说的是，这是一个很好的任务，它教会了我很多关于面向对河北做网站象编程和SimalTalk的知识。谢谢，我们的教授！

然后，我们制作了一个非常模块化的系统，很容易修改它们。当那一天终于到来，当游戏设计被修改时，我们设法在一天内按需要修改程序，让我们顺畅地跟随像开发界面和怪物这样的酷部件。

让我告诉你一个故事：这是一个关于大约25年前开发的系统的故事。它是一个大型瑞典公司的重要商业系统。我说这是一个重要的商业系统，因为它处理的业务是公司收入来源的80%。

从一开始，他们就一直在思考细节，并保存着非常详细的文件，他们还制定了一套严格的要求改变规范，他们希望尽量避免这种制度的变化，因为风险太高，错误会产生巨大的影响。

公司非常担心这一点，所以他们编写了一系列防止系统问题的措施；所有代码都是由第二个人用伪代码注释的，而第二个人不是代码的原始作者。此外，代码的作者不能执行测试。

类似地，已经开发了各种风险管理措施来控制软件规范的制定。对规范编写者进行分级，以确保在提交相关IT业务之前对其进行逐级检查。

25年后，编写文档和控制风险的部门仍然很忙。这项措施很少是一个问题，但效率很低。从计划提交到产品的修改大约需要30周。有超过20个不同级别的批准。这样的指令的程序员称自己为建设者，因为他们真正的工作是将伪代码翻译成COBOL。

在系统中所做的一切是控制风险和改变需求，把稳定性放在第一位。他们相信只要被修改，就会发生事故。不幸的是，对于一个企业来说，唯一能发生的事情就是变化。变化的频率会越来越高。

我想强调的是，第二个故事中的人在他们的生活中没有一个少数民族，他们是优秀的人，但是他们被安排去发展一个以稳定为第一的系统，这才是真正的风险。