书中多次提到软件工程的意义，软件开发的意义在于使程序转变成更有用，创造新事物的纯粹的快乐，开发对他人有用的东西，虽然会产生很多bug，但在解决问题的过程中学习新事物的过程的快乐。同时程序给程序员更大的想象空间，几乎在思考中，凭借自己的想象实现自己概念的设想。但也容易产生问题:1.追求完美，来自他人设定的目标。2.对估算技术缺乏有效的研究，进度并不一定与工作量一致。系统编程的进度安排背后的第一个错误假设就是一切都将运作良好。构思(模型)、实现、交流。编程人员通过纯粹的思维活动即概念以及灵活的表现形式来开发程序。用人月来衡量一项工作的规模是一个危险和带有欺骗性的神话(人员数量和时间并不是可以相互替换的)。软件开发本质上是一项系统工作，即错综复杂关系下的一种实践，因为沟通交流的工作量大，会消耗任务分解所节省下来的时间的个人时间，因此，添加人手并不一定缩短了进度。系统测试进度的安排常常是变成中最不合理的部分，因为系统测试时间难以计算，而不为系统测试安排最后的时间将会是一场灾难。
效率高和效率低的实施者之间个体差异很大，经常能够达到数量级的水平。需要协作沟通的人员数量影响着开发成本，成本的主要组成是相互的沟通和交流，以及更正沟通不当引起的不良结果（系统调试）。对于效率和概念来说，最好由少数干练的人员来设计和开发比如首席程序员：定义功能和性能技术说明书，设计文档，编制源代码以及技术文档；副手：设计的思考者、讨论者、评估人员，详细的了解所有的代码，研究设计策略的备选方案；管理员：仅在项目具有法律、合同、报表、财务方面时，管理员才有全职责任等。这是从个人艺术到公共实践，所有程序员的专业分工，使程序员从文书等杂事中解放出来。都说项目提高技术水平，是因为在实践中总会遇到各种各样的问题，那么就要去解决。无论是通过翻阅书籍，上网搜索，或者是求助他人，亦或是自己调试解决，在这个过程中，我们需要找到问题，弄明白产生问题的原因，最后才能解决它。
书中借巴比伦塔项目的例子，讨论失败的原因是缺乏交流和组织，从而进度灾难、功能的不合理和系统缺陷纷纷出现，追其根本原因是团队成员之间的每个人的理解存在偏差，存在个人推测、群体猜忌等，因而团队之间应尽可能的相互讨论，无论是以正式的简要技术陈述的项目会议，共享的正式项目工作手册，还是非正式的小组讨论都可以让大家相互理解。同时人与人之间的交流和荣和也是相当花时间的，为了节约时间成本，组织结构要做好人力划分和限定职责范围的确定。在人力的划分上，也要注意权力和工作的划分，不允许双领导者的存在。
软件开发人员必须设立规模目标，控制规模，考虑减少规模的方法，在规模预算时，明确所占内存空间、程序对磁盘访问次数、指明每个模块的功能。在整个实现的过程需确保连贯的系统的完整性。编程需要技术的积累，每个项目需要自己的标准组件库。数据的表现形式时编程的根本，所以战略上的突破常常来自于对数据或表的重新表达。在对项目开发和管理时，要做好文档的撰写，例如目标、用户手册、内部文档、进度、预算、组织机构图和工作空间分配等。对每个关键文档的维护提供状态监督和预警机制，同时每个文档本身就可以作为检查列表或者数据库。开发策略上的一些正常变化无可避免，但是项目开发者应事先为一切推测可能发生的情况做好准备，但由于产品易于掌握的特性和不可见性,导致它的构造人员面临着永恒的需求变更，带来的困难是，程序员不愿为设计书写文档，为变更组件团队比为变更进行设计更加困难。程序维护包括修复设计缺陷、新增功能，或者是使用环境或者配置变换引起的调整，其维护成本随用户的增多，所发现的错误也越来越多。在“未雨绸缪”时，先尝试一块块地丢弃和重新设计系统，而不是一次性地完成替换。在构建框架系统时，采用增量开发模型更佳，逐渐精化，这样地设计策略可以使得模块的作用最大化。指定一套策略分配资源以及配置好专业工具是项目经理顺利开发出项目的重要保障。配置好自己需要的目标机器，尽量提高速度以及最大限度的内存，以及保证机器上的标准软件及时更新和实时可用。体系结构工作不但使产品更加易于使用，而且使开发更容易进行且bug更不容易产生。在编写任何代码之前，规格说明必须提交给外部测试小组，以详细得检查说明得完整性和明确性，开发人员无法自己完成这项工作。必须有人对变更和版本控制和文档化，团队成员应使用开发库的各种拷贝工作。
一天一天进度落后比起重大灾难更难以识别，更加不容易防范和更加难以弥补，所以在控制大项目得第一个步骤就是制定进度表，包括任务和日期。任务里要有具体的、特定的和可度量的事件以及清晰的定义。期间内对事件长短的过高估计会随活动的进行持续下降，过低估计直到计划结束日期之前大约三周左右才有明显变化。所以每两周进行仔细修订的活时间估计随着开始时间的临近不会有太大的变化。整个项目要有完整的评审机制，使所有的成员可以通过它了解真正的状态，因而里程碑的进度和完成文档是关键。特别是这句话“bell实验室监控系统项目的v.a.vyssotsky提出，关键的工作是产品定义。许许多多的失败完全源于那些产品未精确定义的地方，细致的功能定义，详细的规格说明，规范话的功能描述说明以及这些方法的实施，大大减少了系统中必须查找的bug数量”。虽然这句话的意思只是说明精确定义产品将减少bug的数量，但我看到了系统分析的最重要的工作——产品定义。现在，许多开发人员嘴里口口声声说也做过需求调研、系统分析、系统设计，但大多数没有涉及到产品定义的深度，严格意义上不能叫做系统分析。我想这句话对我的以后想从事软件研发的工作有很大的帮助。