《人月神话》读后感
《人月神话》读后感（五篇范例）
《人月神话》读后感（五篇范例）第一篇：《人月神话》读后感《人月神话》读后感在软件领域中,很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。
Brooks 博士为人们管理复杂项目提供了最具洞察力的见解,既有很多发人深省的观点,又有大量软件工程的实践,影响着一代又一代….《人月神话：软件项目管理之道》（英语：The Mythical Man-Month: Essays on Software Engineering）是由IBM System/360系统之父佛瑞德·布鲁克斯所著经典文集，全书讲解软件工程、项目管理相关课题，被誉为软件领域的圣经，内容源于作者布鲁克斯在IBM公司System/360家族和OS/360中的项目管理经验[2]。
该书于1975年首次发行（ISBN 0-201-00650-2），并于1995年重新发行纪念版（ISBN 0-201-83595-9），其中新增了对〈没有银弹〉一文的评论和回应，与4个额外的新章节。
书开始就形象有有趣的把软件危机比作：焦油坑 ========== 史前史中,没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。
上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。
它们挣扎...让我感觉到，软件开发过程中所遇到困难是多么的多，开发多么艰难。
当我看完《人月神话》突然感觉到这本书比《The Clean Coder: A Code of Conduct for Professional Programmers 》更完美，是为软件开发经验的天马行空总结。
比《Beautiful code》更为有远见，把我从充实代码的清晰简介升华，拓展到软件开发的高层度，一个周密，准确，明朗的开发需求分析，可行性研究，软件实现是软件开发的完美递进，他们相互辅助，相互促进，如海浪一层的推着前浪奔向远方，而《人月神话》如软件工程开发经济的精华，碧玉。
在《人月神话》面前《设计模式》、《原型设计》、《灵活软件开发》、《面对对象思维》、只不过是冰山一角。
人月神话读后感
人月神话读后感书中的“人月神话”指的是在软件工程过程中，添加更多的人力资源并不意味着可以在更短的时间内完成任务。
布鲁克斯通过丰富的实例和案例，解释了造成这种现象的原因，并提出了一些解决方案。
首先，布鲁克斯强调了人员沟通的重要性。
他认为，软件工程是一个集体创作活动，团队成员之间的沟通是至关重要的。
只有良好的沟通和密切的合作，才能够确保项目的顺利进行。
而人员增加会增加沟通的复杂性，导致信息传递困难，从而拖慢了项目的进度。
其次，布鲁克斯强调了软件工程的复杂性。
他认为，软件工程是一项非常复杂的任务，涉及到许多不确定性因素。
因此，增加人力资源并不能够简单地提高生产效率，相反可能会导致更多的混乱和复杂性。
他提到了“招募人月”这个概念，即增加人力资源可能会在短期内提高生产效率，但在长期内会带来许多问题和挑战。
布鲁克斯还提出了一种解决“人月神话”的方法，即将项目分为独立的模块并分配给小团队进行开发。
这种方法可以减少团队之间的沟通，提高开发效率。
同时，他强调了软件工程师个人技能的重要性。
他认为，卓越的软件工程师往往可以对项目进行正确的判断和决策，并提出高效的解决方案。
因此，公司应该注重培养和发展软件工程师的个人技能和专业素养。
在读完《人月神话》后，我深刻认识到了软件工程的复杂性和团队协作的重要性。
在实际工作中，我也经常遇到类似的问题，尤其是在项目进度紧迫的情况下。
在过去，我一直认为增加人力资源可以提高开发速度，然而事实证明并不是这样。
通过读这本书，我对软件工程项目的管理有了更深入的了解，也掌握了一些实用的解决方法。
首先，我开始更加注重团队内部的沟通和协作。
我意识到在团队中，每个人的意见和建议都非常重要，只有通过充分的沟通和合作，才能够取得最好的工作结果。
因此，我会定期组织团队会议，让大家就项目的进展和问题进行讨论，并共同制定解决方案。
同时，我也更加注重团队成员之间的互相支持和协助，通过合理分配任务，充分发挥每个人的优势，提高整个团队的工作效率。
《人月神话》读后感
《人月神话》读后感
《人月神话》是一本经典的软件开发管理书籍，作者弗雷德里克·布鲁克斯通过讲述自己在IBM的项目经验，对软件开发过程中的一些问题进行了深入的思考和总结。
这本书虽然是在20世纪70年代写的，但其中的观点和原则在今天依然有着很大的启示意义。
其中最重要的观点之一是布鲁克斯提出了“带来人越多，项目越慢”的概念，即在一个软件项目中，添加更多的人力并不能加速项目的进展，反而可能会拖慢整个团队的工作。
这是因为在软件开发中，人力并不是可以无限量放大的资源，每一个新成员要花费一定的时间来适应项目的环境和沟通协调，而且不同成员之间的协作也可能会带来额外的沟通成本。
因此，布鲁克斯提倡在开发中尽量保持稳定的团队规模，并且强调进行好的项目规划和任务分配，以确保开发进展的高效和质量。
此外，布鲁克斯还讨论了关于项目中进度和质量的问题，他指出时间、人员、功能三者之间是有着天然的矛盾的，在面对这种矛盾时，项目管理者需要进行适当的取舍和折中。
他还提倡采取模块化的开发方式，将复杂的软件系统划分为较小的、可独立开发的模块，这样不仅能够更好地管理和控制开发过程，还能够提高开发的灵活性和可维护性。
总的来说，读完《人月神话》我深感布鲁克斯在软件开发管理方面的经验和思考是非常宝贵的。
他对项目管理、团队协作和开发流程的一些观点仍然非常适用，可以帮助我们更加有效地管理和组织软件开发项目。
这本书对于任何从事软件开发和项目管理的人士都是一本必读之作，我相信它会给读者带来很多启发和思考。
人月神话读后感
人月神话读后感《人月神话》是一本由计算机科学家弗雷德里克·布鲁克斯所写的经典著作，书中以自身的亲身经历和观察为基础，探讨了如何管理和开发大型软件项目的一些重要原则和方法。
阅读完《人月神话》，我深深地被书中的观点和思考所震撼，对于软件开发和项目管理的理解有了更深入的认识。
书中，作者首先提到了“人月神话”这一概念，即认为增加人力资源可以缩短项目的进度。
然而实践中，情况却完全相反，项目反而更加拖延。
布鲁克斯通过数个实际案例说明了这个问题的原因，主要是因为沟通成本的增加和人员的组织问题。
他提出了著名的“布鲁克斯法则”，即“人越多，开发时间越长”。
作者还深入探讨了软件开发中的一些重要问题，如程序员的生产率、项目管理、团队组织等。
他认为，一名出色的程序员的价值相当于普通程序员的数十倍，而且编程工作的本质是创造性的工作，并不适合通过时间来衡量。
他提倡合理的工作时间，并强调了程序员的舒适度对于工作效率的影响。
在项目管理方面，作者提倡将项目分解成小的部分进行开发，并强调了需求分析的重要性。
他指出了软件开发中经常发生的需求变更问题，以及如何通过合理的时间规划和团队协作来解决这个问题。
他还对管理者的角色进行了深入的思考，认为管理者应该给团队提供清晰的目标和方向，并保持开放的沟通和透明的决策过程。
在书中，作者还介绍了一些关于人员组织和团队管理的经验和原则。
他认为，团队的成功不仅仅取决于个人的能力，更取决于人员之间的相互合作和协调。
他引用了傲慢者法则和思科系统的成功经验来说明团队合作的重要性。
他主张鼓励团队成员之间的交流和分享，提倡团队精神和集体创造，以实现项目的成功。
阅读完《人月神话》，我深刻地体会到了软件开发和项目管理中的一些重要规律和原则。
我认为，软件开发是一项复杂而创造性的工作，需要合理的时间和资源来完成。
而项目管理则需要合理的规划和组织，以及良好的沟通和协作。
只有通过合理的方法和思考，才能够提高软件开发的效率和质量。
人月神话读后感
人月神话读后感《人月神话》是一本由弗雷德里克·布鲁克斯所著的计算机领域经典著作，它深刻地剖析了软件开发过程中的种种困难和挑战，提出了许多颠覆性的观点和理论。
在读完这本书后，我深受启发，对软件开发这一领域有了更加深入的理解和认识。
首先，我被书中提出的“人月神话”这一概念所震撼。
在书中，布鲁克斯指出，增加人手并不能缩短软件开发的时间，反而可能会延长项目的完成时间。
这一观点颇具启发性，因为在我以往的认知中，增加人手应该可以加快项目的进度。
然而，书中通过实际案例和数据分析，清晰地展现了增加人手可能导致的沟通成本、协调成本和学习成本等问题，从而使得项目的进度反而受到影响。
这一观点对我来说是一种颠覆性的认知，使我对软件开发的管理和组织产生了新的思考。
其次，书中对软件开发过程中的种种挑战和困难进行了深入的剖析。
例如，书中提到了软件开发中的“二次系统效应”，即在开发过程中，随着系统的不断完善和修改，系统的复杂性会呈指数级增长。
这一观点让我对软件开发的复杂性有了更加深刻的认识，也使我意识到在软件开发过程中需要更加注重系统的设计和架构，以避免二次系统效应带来的种种问题。
此外，书中还提到了软件开发中的“饥饿艺术家效应”和“进度不良的现象”，这些都是软件开发过程中常见的问题，通过深入的剖析和分析，使我对这些问题有了更加清晰的认识，也为我今后在软件开发过程中避免这些问题提供了宝贵的经验和教训。
最后，我被书中对软件开发管理和组织的种种建议所深深吸引。
例如，书中提到了“参与式管理”和“集成式管理”等概念，这些管理理念都是为了解决软件开发过程中的种种挑战和困难而提出的。
通过对这些管理理念的深入剖析和分析，使我对软件开发管理和组织有了更加深入的理解，也为我今后在软件开发过程中的管理和组织提供了宝贵的经验和启示。
总之，《人月神话》是一本极具启发性和深度的书籍，它不仅为我对软件开发的认知和理解提供了新的视角，也为我在软件开发过程中遇到的种种挑战和困难提供了宝贵的经验和教训。
人月神话读后感2000字
人月神话读后感2000字第一篇：人月神话读后感2000字读《人与神话》有感翻开《人月神话》这本书的第一感受，感觉看这本书不像是在看一本和我们学的相关的书，书中用了很多的形象的比喻，来阐述项目管理中的一些问题，让人以很轻松愉悦心态去阅读。
书开始就形象有有趣的把软件危机比作：焦油坑。
史前史中,没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。
上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。
它们挣扎...让我感觉到，软件开发过的过程中，会有很多困难，很多的挑战。
看完此书后，我发现人月神话无处不在，其实在我们做软件工程来说，此书已经渗透进去了。
本书作者为人们管理复杂项目提供了颇具洞察力的见解，既有很多发人深省的观点，也有大量的软件工程实践。
大型编程项目深受由于人力划分产生的管理问题的困扰，保持产品本身的概念完整性是一个至关重要的需求。
《人月神话》探索了达成一致性的困难和解决的方法，并探讨了软件工程管理的其他方面。
的在刚刚进入软件工程学习时，老师就和我们说了一些关于“软件项目开发的完成与增加人员的问题”，这句话听起来通俗易懂，道理很简单明了，但实现起来却遇到了相当大的困难，这也是我在阅读完成《人月神话》时最大的感受。
全书的第二章说的就是人月神话的关系。
“一切都将运转良好”在软件工程中是不适用的；完成工作的人数与时间是不能进行简单的互换的，因为沟通需要额外的成本。
我想这种问题的出现主要是就订单项目而言，因为人员的增加主要是因为客户所要求实现的东西并没有在计划的时间内收到满意的答复和应得的功能与效益。
所以项目开发人员不断的增加，本书作者布鲁克斯得出的结论是显而易见的：“向进度落后的项目中增加人手，只会使进度更加落后”。
如果不想加班，不想削减功能，不想推迟发布日期，那么唯一的方法还是只有加人。
加足够的人。
而且不要逐步加入，一定要一次性加入。
要小心的是，新加入的人可能对原来的组织造成冲击，或者对原来的设计有不同意见，特别是我想如果如果有比较强大的设计者时就要当做新组建了一个团队。
人月神话读后感
《人月神话》读后感在阅读这本书之前,已经很多次听到关于人月神话这本书以及他的作者Brooks的消息了. 在软件领域, 《人月神话》具有深远影响力而且畅销不衰.这一次,正好老师的作业要求我们阅读这本书,我终于使有机会阅读这本经典之作了.在这过去的几个星期里面,一点一滴的阅读这本书,粗略的了解了这本书.首先,让我印象深刻的是《人月神话》提出的两条著名的法则：1、人月神话：向一个已经延后的项目中投入更多的人力资源只会让它更延后。
人月神话看上去这么浪漫的名字，原来并不是真的说神话故事，作者阐述的主要观点是在软件开发项目上项目进度和增加人员这两个概念是不能互换。
虽然已经时隔20多年了，这本书依然给我震撼，一是让我惊讶的是，美国20年前软件项目所面临的问题，在我们现在依然如此，糟糕的情况没有改变，大家仍旧在焦油坑里挣扎，而且看上去没有解决办法. 当读到“是当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。
这就像使用汽油灭火一样，只会使事情更糟。
越来越大的火势需要更多的汽油，从而进入了一场注定会导致灾难的循环。
这让我明白了一个重要的道:理项目的进度是不能够光靠人力的增加来推进的.2、没有银弹:没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。
虽然现在有不少人对他的观点持反对或不同意见，但我始终觉得他的观点是对的——根本和次要问题的划分以及定义。
作者认为软件开发困难的部分是概念的结构，如规格化、设计和测试等概念的结构，而不是概念的表述和实现概念，虽然实现概念可能占用了小于90%的时间，就如现今的软件开发一样，系统分析通常占用的整个项目开发时间不超过20%，而80%的时间花在编程上一样。
这两个原则已经在过去的几十年间得到了验证.我相信在未来,它以依旧是成立的.另外,在焦油坑那一章里面,有一句话让我难以忘怀:岸上的船,如同海上的灯塔,无法移动.是呀,过去几十年的大型系统开发就犹如这样一个焦油坑，很多大型和强壮的动物在其中剧烈地挣扎。
人月神话读后感
人月神话读后感《人月神话》读后感《人月神话》是一本由弗雷德里克·布鲁克斯所著的软件工程领域经典著作。
这本书首次出版于1975年，至今已经被翻译成多种语言并广泛流传。
在这本书中，布鲁克斯提出了许多关于软件开发的观点和原则，对软件工程领域产生了深远的影响。
在读完《人月神话》之后，我深受启发。
这本书不仅仅是一本关于软件开发的著作，更是一部关于团队合作、项目管理和创新思维的指南。
布鲁克斯在书中提出了许多深刻的观点，让我对软件开发这个领域有了更深入的理解。
首先，我深受布鲁克斯关于“人月神话”的观点所感动。
在书中，他指出了一个常见的误区，即认为增加人手就能够加快项目的进度。
然而，布鲁克斯指出，人手的增加并不一定会带来效率的提升，反而可能会导致更多的沟通成本和管理成本。
这一观点让我深刻地意识到，团队的规模并不代表团队的效率，而是需要通过合理的规划和管理来提高项目的执行效率。
其次，布鲁克斯在书中提出了“二次系统效应”的概念。
他指出，当一个软件系统经过一次开发之后，随着需求的变化和新的功能的增加，系统的复杂度会呈指数级增长。
这一观点让我意识到，软件开发并不是一次性的任务，而是需要不断地进行迭代和优化。
只有不断地对系统进行重构和改进，才能够应对不断变化的需求和挑战。
另外，布鲁克斯还在书中提出了许多关于项目管理和团队合作的建议。
他强调了团队的沟通和协作的重要性，以及项目计划和进度的管理。
这些建议无疑对我在实际工作中的团队合作和项目管理产生了积极的影响。
我意识到，一个成功的项目不仅需要技术上的创新，更需要团队之间的有效沟通和协作，以及合理的项目规划和管理。
总的来说，读完《人月神话》之后，我对软件开发这个领域有了更深入的理解。
布鲁克斯在书中提出的观点和原则，让我意识到软件开发不仅仅是技术上的挑战，更是一个需要团队合作、项目管理和创新思维的领域。
我相信，这些观点和原则将对我未来的工作产生深远的影响，帮助我更好地应对软件开发中的各种挑战和问题。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
《人月神话》读后感
2005-7-6 字数：4071 不同的社会经验，不同的思想状态，对读本书的心得也不一样，我在此说说我的读后感，书中有许多非常好的观点，但我只把我感触最深的写下来。
这确实是一本很值得多次阅读的好书，每次阅读可能都能从中得到一些提示。
1.外科手术队伍The Surgical Team 项目经理在项目的初期必须清楚的估计项目的人月运作模式（时间、人力在项目各阶段的分配），例如什么时候需要出什么样成果，决定了什么时候需要什么样的人加入项目，这是项目经理的责任。
2.贵族****，民主政治Aristocracy，Democracy，System 要获得概念的完整性，设计必须由一个人或具有共识的小组来完成。
有四个问题：1。
如何得到概念的完整性2。
是否要有一位杰出的精英，或者说是结构设计师的贵族专制.....
3.如何避免结构设计师产出无法实现或代价高昂的技术规格说明，使大家陷入困境。
4。
如何才能与实现人员就技术说明的琐碎细节充分沟通，以确保设计被正确地理解，并精确地整合到产品中。
对1。
2。
4的回答基本上都可以找到，但第3个似乎找不到。
3.画蛇添足The Second-System Effect 讲述的基本都是基于IBM 360操作系统以及编译程序等方面的经验，讲述如何避免开发第二个系统的风险，认为开发第二个系统的设计师设计出来的系统是最危险的，因此要求他们自律。
4.贯彻执行Passing the word 印象比较深刻的是＂体系结构设计人员必须为自己描述的任何特性准备一种实现方法，但他不应该支配具体的实现过程。
＂
5.为什么巴比伦塔会失败Why did the Tower of Babel Fail？讲述巴比伦塔会失败的原因是缺乏交流。
6.胸有成竹Calling the Shot 主要讲述如何计算编程时间，以及提出几个人的经验算法。
讲述的各种算法可能都不太适合与现在的高级语言，但Portman的观点仍然
适合现在，即编程人员实际的编程时间只有50％，其他的时间都花在了无关的琐碎事情上。
7.削足适履Ten Pounds in a Five-Pound Sack 主要讲述程序占用的空间等，在70年代比较突出，但现在好多了。
8.提纲擎领The Documentary Hypothesis 说明文档的作用9.未雨绸缪Plan to Throw One Away 唯一不变的是变化本身。
在大型项目中，项目经理需要有两个和三个顶级程序员作为技术轻骑兵，当工作繁忙最密集的时候，他们能急驰飞奔，解决各种问题。
讲述技术人员与项目人员的互换是，对我有一定的提示，但图中IBM的两条职位晋升线，不太理解。
10.干将莫邪Sharp Tools 主要讲述项目中管理好各种工具的重要性，项目经理首先要制定一种策略，让各种工具成为公用的工具，这样才能使开发、维护和使用这种工具的开发人员的效率更高，这种工具可能是开发人员开发出来的，也可能是使用现有的，可能是通用的，也可能是专用的或个人偏好的。
比如：文档编写工具、开发工具（包括各种不同开发平台）、调试工具、测试工具、数据库工具、版本管理、项目管理工具等。
11.整体部分The Whole and the Parts 一读这一章，就让我感触颇深，特别是这句话＂BELL实验室监控系统项目的V.A.Vyssotsky提出，＇关键的工作是产品定义。
许许多多的失败完全源于那些产品未精确定义的地方＇，细致的功能定义，详细的规格说明，规范话的功能描述说明以及这些方法的实施，大大减少了系统中必须查找的BUG数量＂。
虽然这句话的意思只是说明精确定义产品将减少BUG的数量，但我看到了系统分析的最重要的工作——产品定义。
现在，许多开发人员嘴里口口声声说也做过需求调研、系统分析、系统设计，但大多数没有涉及到产品定义的深度，严格意义上不能叫做系统分析。
这句话对我的以后想从事系统分析工作有很大的帮助。
这一章余下的内容，也值得一看，虽然有些地方有些过时，但剔除BUG的设计以及部分测试/调试方法仍值得一看。
12.祸起萧墙Hatching a Catastrophe 这章节说明使项目进度拖后的最大原因不是重要的事件，如新技术、重组等，而是一些琐碎的小事，每件小事只耽误半天或一天时间，但这种小事多以后，
将使项目的进度严重拖后。
项目对于公司就如程序对测试工程师一样，如果不了解它，它就是一个黑盒子，如果不打开这个黑盒子，你可能永远不知道盒子里面有什么。
这部分描写项目经理以及小组主管的一些”:.sun525.co>心理咨询，值得一看。
13.另外一面The other face 本章说明程序的另一面——文档。
不了解，就无法真正拥有——歌德，引用的歌德的话来描述文档对客户的重要性，提出客户需要什么样的文档以及文档的格式和包含的内容，指出当时存在的大多数文档只描述了树木，形容了树叶，但没有整个森林的图案。
想想，这种情况在现在仍然没有改变。
于是提出了两个观点： 1.流程图：流程图是被吹捧得最过分的一种程序文档。
许多程序甚至不需要流程图，很少程序需要一页以上的流程图 2.自文档化（self-documenting）的程序：提出文档与程序合为一体，能很好的解决文档与程序分开造成的文档过时的问题，并说明了在程序中加入文档的一些方法和技巧。
2002年，我看到一位网友关于文档与程序合一的文章，当时就觉得是个好方法，没想到70年代，老美已经提出来了。
14.没有银弹-软件工程中的根本和次要问题(No Silver Bullet-Essence and Accident in software Engineering) 这是一篇论文，发表于1986年，我自认为我的理论水平没有上升到可以对他的论点和论据做出怀疑或质疑的结论，我只是说说我的感想。
人狼是传说中的妖怪，只有银弹才能杀死他。
认为软件项目具有人狼的特性，因为软件项目也可能变成一个怪物，一个落后进度、超出预算、存在大量缺陷的怪物。
通过软件系统的内在特性复杂性、一致性、可变性和不可见性来分析说明了软件天生就没有银弹。
试图通过分析软件问题的本质和很多侯选银弹的特征来探究其中的原因。
他行动的第一步是将大块的“巨无霸理论”替换成“微生物理论”。
这个变化的过程告诉你，进步是逐步取得的，伴随着辛勤的劳动，对规范化过程应进行持续不懈的努力，而这个努力的过程相应的就诞生了软件工程。
对软件工程诞生的原因做出这样的解释，我觉得符合外国思维的特点，这正是国人所缺乏。
记得有一位朋友说过，中国妈妈与德国妈妈的区别，他说，如果手里拿的
针掉到地上了，中国妈妈的第一反应是估计针掉下去的范围，然后在这个范围里面找，可能很快就找到了，也可能一直都找不到；但德国妈妈不同，她会拿一根粉笔来，把整个屋子画成一个大圈，接着把大圈分成许许多多的小圈，然后再到每个小圈里找，虽然比较慢，但最终肯定可以找到。
仔细想象，大多数情况下，中国妈妈都会找到得比较快，这确实符合大多数中国妈妈的思维习惯，每个中国妈妈都这样找，这好象是与生俱来的本事，但为什么德国妈妈没有这个本事呢？是德国妈妈笨吗？为什么中国妈妈也有找不到的情况？而德国妈妈，虽然速度慢了点，却始终能够找得到？如果把这件故事推而广之，多年以后，德国妈妈创建了找针工程，她通过多次找针的实验数据，分析出针掉到整个房间中各个小圈的概率，总结出针在哪个小圈的概率最大，很快就可以找到针，找针速度早已高过中国妈妈，而中国妈妈还在依循与生俱来的本事。
你能说德国妈妈笨吗？为什么中国妈妈和德国妈妈会有这么大的区别？是德国妈妈把大块的“巨无霸理论”替换成“微生物理论”吗？我觉得是是，你说呢？在后面的论述中用数学和物理的发展为例子也说明了，这种思想的成立。
余下的把软件工程按“巨无霸理论”替换成“微生物理论”的过程详细的说明，值得看，我关注的不是具体的内容，具体内容可能有些不合适宜，我关注的是的思考方式以及处理方法，这是非常重要的。
在“以往解决次要困难的一些突破”和“银弹的希望”章节，从概念上讲述了软件的发展，其中讲到“专家系统”时，使我想起一部科幻电影，忘了电影名字了，有个情节大致是这样的，一位非常有经验的主管死后，有一名较优秀的下属接任，但这时出现了一位非常厉害的敌人，这位新主管无论如何也战胜不了敌人，这时想起了以前的主管，心想前主管一定有办法对付这个敌人，而前主管的大脑就存放在系统里，。