读完《梦断代码(Dream In Code)》样书，我感觉心情有点沉重，Chandler项目的结局，它失败了，它成了众多失败软件项目中的一个。这个结局让那个我感受到软件实在是太难了，对我来说软件业的大牛是无所不能的，几乎所有的问题都可以解决，然而我错了，我并不能理解写软件的艰辛，虽然他们失败了，但是我从心里佩服他们。
今天的软件项目，已经成为一个错综复杂的建筑工程，不断变化的应用环境（包括使用者），使得软件需求被不断更新，今天100个需求，明天减10个、改5个、加80个，这在不断公开发布的升级版开源软件以及Web网站应用中表现的就颇为明显。为了满足这种需求及由此需求所带来的编程及调错成本，人们已经发明了众多方法，比如一旦项目被人们认为足够“大”，就用面向对象来代替面向过程，以及使用面向对象所衍生的面向组件-----但所有的这些，面对复杂的外部需求，程序员们感到还是远远不够。
《梦断代码》里同样在反映这个现实，描述了大量导致软件项目进展困难的问题。作者无法给出一种灵丹妙药，甚至没有表达太多自己对于解决问题的倾向性意见。但其中提到了一种案例是“实用最小主义”：尽量少的人。这意味着沟通成本的降低，意味着更容易较为完整的相互理解彼此的思路，意味着软件团队开发中涉及最复杂的因素“人”的问题在理论上的减少。尽量少的时间。这意味着人出于谨慎原则会更青睐于选择自己最熟悉的解决方案，这里的解决方案指的是平台、框架、思路等等。尽量少的功能。这意味着只能选择最有把握实现且最为贴近根本需求的功能。大多数软件工作人员在继续研究和创造新的方法论，这种“实用最小主义”的论调对他们来说显然是一个保守以求项目安全的方案，归根结底，它是在减少问题的理论上限和发生的概率。
我倒愿意多考虑一些乐观的因素，这么多年来，积累的方法实际上已经大大提高了我们解决问题的能力，类库和框架越来越庞大的同时也的确在为我们减少问题。“实用最小主义”这样的条款和“方法论”并不冲突，他们总是在相对的变化，也就是说，随着方法论的不断完善扩充，“实用最小主义”的门槛实际上也在不断提高：今天一个被3名程序员认为棘手的功能，可能2年后一个程序员独立就可以轻松在某个框架上完成。
《梦断代码》中对软件工程所面临的种种困难与艰难的描述，即便再过5年读也许都不过时。因为正如原作者所说，书中描写的是一队人马并肩扛起代码大石，虽历经磨难仍欲将其推上山顶的故事，而正是这种故事成就着今天全世界亿万台服务器和PC机上运行的各种软件，成就着人类不断超越实现更伟大的梦想。