第一次听说人月神话还是在大一上学期的导论课那会儿，那会儿好像就已经确定了自己要学软件，于是就去问王建民老师能不能给我推荐几本软件工程方面的书，我想要提前自己学学，以为老师会给我推荐一些某种语言类的学习书，但是貌似不是，他推荐的一堆书里面其中就有这本《人月神话》，当时的我真的不理解，别的书还好，像是梦断代码，好歹里面有个代码俩字儿，但这个……那个人月是啥意思，人和月亮的神话故事？？可是这和软件工程又有什么关系呢？也许是单纯因为好奇心吧，趁着双十一我就买了一本，但是好奇心来得快去的也快，书到手以后，我想着反正自己已经有了啥时候看都行，就一拖再拖，直到这个寒假，我才慢慢地揭开了它神秘的面纱。
原来所谓人月是指人员和时间的关系，作者认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话，书名由此得来。书中提到当一项任务由于次序上的限制不能分解时，人手的添加对进度没有任何帮助，而对于可以分解的，其子任务之间又需要相互沟通和交流，而沟通交流的工作量非常大，他很块会消耗任务分解所节省下来得个人时间。从而，添加更多人手，实际上是延长了而不是缩短了时间进度。由此向进度落后的项目中增加人手，也只会使进度更加落后！
建立怎样的组织架构是项目成功的关键。书的第三章作者提到了Mills的提议“大型项目的每一个部分由一个团队解决，但是该队伍以类似外科手术的方式组建，而并非一拥而上”。即提倡外科手术式的团队组织：就是一个主治大夫，其他的如助理大夫，护士等，都是配合主治大夫来进行手术。在软件开发组织上的过份民主，往往带来的是没有效率和责任，参与其中的人想法太多，层面参差不齐。所以，软件开发的组织，应该借鉴外科手术式的团队方式，有一个主要的负责人，其他人都是分工协作的副手，这样效率最好，结果最好。
概念完整性是系统设计中最重要的考虑因素。软件项目的核心概念要由很少的人来完成，以保证概念的完整性。少就是多，项目的定位需要和功能多少的权衡。太多的想法，使项目没有焦点，什么都要放进去，结果什么都做不像。我想起了作者书上提到的一个例子，在选择是让体系结构的团队承担该工作，可以出色完成任务，但是比所允许的进度多了三个月，而且程序实现团队的150人只能坐在那里干等10个月；还是让程序实现队伍来负责该工作。可能仍将推迟三个月，而且质量更加低劣。结果将工作分派给了后者，结果也确实如此。更糟的是，由于概念完整性的缺乏，至少增加了一年的调试时间。而造成这个错误决策的决定性因素正是时间进度和让150名编程人员参与工作的愿望。同工作广泛的水平分割相比，垂直划分从根本上大大减少了劳动量，使交流彻底地被简化，概念完整性得到了大幅提高。获得概念完整性十分重要，宁可省略一些不规则的特性和改进，也不提倡独立和无法整合的系统。对我来说，平常的编程也是一样，一定在下手之前头脑里先有一个明确清晰的设计思路和整体规划，这样看似是浪费时间，其实大大节省了编程进度，像自己原来那种边编程边想的做法既容易出错又消耗时间。