Chandler项目的结局，它失败了，它成了众多失败软件项目中的一个。之前一直以为软件业的大佬是无所不能的，几乎所有的问题都可以解决，然而我错了，我并不能理解写软件的艰辛，虽然他们失败了，但是我从心里佩服他们。今天的软件项目，已经成为一个错综复杂的建筑工程，不断变化的应用环境（包括使用者），使得软件需求被不断更新，今天100个需求，明天减10个、改5个、加80个，这在不断公开发布的升级版开源软件以及Web网站应用中表现的就颇为明显。为了满足这种需求及由此需求所带来的编程及调错成本，人们已经发明了众多方法，比如一旦项目被人们认为足够“大”，就用面向对象来代替面向过程，以用面向对象所衍生的面向组件-----但所有的这些，面对复杂的外部需求，程序员们感到还是远远不够。
《梦断代码》里同样在反映这个现实，描述了大量导致软件项目进展困难的问题。作者无法给出一种灵丹妙药，甚至没有表达太多自己对于解决问题的倾向性意见。但其中提到了一种案例是“实用最小主义”：尽量少的人。这意味着沟通成本的降低，意味着更容易较为完整的相互理解彼此的思路，意味着软件团队开发中涉及最复杂的因素“人”的问题在理论上的减少。尽量少的时间。这意味着人出于谨慎原则会更青睐于选择自己最熟悉的解决方案，这里的解决方案指的是平台、框架、思路等等。尽量少的功能。这意味着只能选择最有把握实现且最为贴近根本需求的功能。大多数软件工作人员在继续研究和创造新的方法论，这种“实用最小主义”的论调对他们来说显然是一个保守以求项目安全的方案，归根结底，它是在减少问题的理论上限和发生的概率。
个人感受：开发软件本来就是一个不断探索的过程，在开始阶段没有人是全知全能的，里面也存在着会拦住所有人的困难， 二软件的开发过程就是解决这些困难。在之前一直以为大佬们是因为全都会才做得出来一些大项目，而现在才发现他们是因为完成了任务才学会了知识。所以以后做任务时的心态要调整，不要把完成任务想象的那么难。