此为梦断代码第二篇
这里的被无数奇点拖住的Chandler，恰恰映照了人月神话中的一句话，没有银弹。
在书的最后，韩磊的译后记中已经提到了Chandler项目的结局，它失败了，它成
了众多失败软件项目中的一个。这个耗资巨大的工程留下了什么？无数人在思考，
作者给出了他的见解：
1.尽量少的人
最复杂的因素：沟通成本的降低以及更好的一致性。
2.尽量少的时间
最有效的开发流程。
3.尽量少的功能
最有把握实现而且是硬性刚需的功能。
这三点减少了问题的理论上限和发生概率。
我想，如果当初Chandler设想的最初版本能够满足上列三个需求，也许已经成功了，
可惜经验的得来往往意味着牺牲.如今，完善的开发流程例如瀑布模型，敏捷开发，
还有团队协作模式，或多或少得益于此。一些看上去很棒的事情其实并不是有益于工程，
例如百花齐放的想法，使用编外人员开发，使用不成熟但是高端的技术，试图创新等等，
Chandler在漫长的岁月里，替后辈趟过了一个又一个雷区。