但这是否解决了问题呢？这个问题可能是解决了，但还会有很多类似的问题。所幸的是，这个错误*终是被发现了，可能软件中还存在大量未被发现的错误，这些才是*的。其实这个问题的根源在于，程序员之间的沟通不够。而要解决这个问题，我们认为，只能从文化上去想办法，提倡沟通，提倡协作。而我们的分析框架中并没有文化这一项。理由是，文化的主题超出了我们讨论的范畴。《创建软件工程文化》一书是一本讨论文化的优秀书籍，如果大家有兴趣，可以进一步的阅读。
所以，这里我们可以知道一个道理，软件工程、项目管理其实并没有什么非常难的地方，我们看很多书把很多问题都提到纯理论的高度，反而给读者造成了困扰。很多读者的来信中，问到一个同样的问题，我希望在我的团队中引入软件工程，有些人说从需求管理开始比较好，有些人说从配置管理开始比较好，到底应该从哪里开始呢？就拿这个例子来说，为什么我们对一个异常管理如此的关心呢？为什么不做需求管理，或是上CMM呢？那该多酷啊！问题就在这里，软件开发是为了给客户带来价值，就像UMLChina的名言，软件以用为本，而不是以酷来衡量的。异常管理的*终目的是为了提高软件质量，这是立竿见影的效果，能够给老板、给同事以信心。需求管理和CMM当然也可以达到这种效果，问题是，异常管理几乎不需要多少的成本，却能够达到直接的效果，这种好事，为什么不做？
事情到了这一步，程序员的行为已经开始慢慢规范了。注意，我们先激发大家的兴趣，再使用制度来规范行为。但是，这里还有一个问题，我们之前提到，使用新技术一定会在短期造成生产力的降低。好的，现在我们确实发现生产力降低了，因为程序员必须思考什么时候使用异常，如何使用，并编写文档和测试。所以我们在之前已经做了一件事，就是取得老板的支持，这一点至关重要。这也许也是属于文化的范畴吧。
好了，软件过程是需要不断的改进的，我们的案例讨论也体现了这一点，这个案例还可以讨论很多，但是处理的思基本一致。找出可能存在的问题，思考相应的对策来规范行为，再发现问题，再规范行为。这样形成了一个不断循环不断进步的过程。