语言只是工具，就像在第一章中提到的那句话“成天讨论这门语言好，或者那门语言坏的人，甚至是可悲的。”语言是用来实现我们想法的工具，仅此而已。
就像自然界中永恒的定律：弱肉强食。这句话从自然界起源到现在都无可置疑，而“程序=算法+结构”这个等式在开发的世界里也有着相同的地位。
经过无数次实践的积累，方法也就呼之欲出。随着一遍遍的回顾、理解和分析，经验也在不断地增加。这不是你不断写代码就能实现的，不断地写只会让你的错误越来越多，你甚至会在同一个地方跌倒无数次，你以为你得到的是经验，实际上，你只是在浪费存储空间。就像高三做卷子，每次做完老师都要求你改错，改错的过程就是经验积累的过程。对于编写代码来说，这句话依旧成立。
做什么事都要先有个规划，先做什么，再做什么，你做什么，我做什么。这一切都需要通过角色间的沟通来解决，不仅开发团队间需要沟通，公司与客户之间也要有沟通，你要知道客户的最终期限，客户要知道你为啥跳票。（这段说的和过程有很大关系么？窃以为用规划这个词会更好一些）
软件规模的不断增大是工程出现的根本原因。项目的“复杂”可能要求不同的知识领域的角色参与，而“庞大”则要求更多的 (人力、技术与管理 )资源。 “团队”作为开发行为的模式，是软件规模和复杂度渐次累积的结果。从之前一个人编一个杀毒软件，而现在微软、谷歌几万人的开发团队，都证明一个事实：团队必将越来越庞大，因为软件规模必将越来越复杂。没有团队意识的软件公司将在高度过程 化、通晓方法理论、拥有大量工具的集团军面前必将一触即溃。
人们在茫然之中，渐渐地抛弃了原有的观点，开始探索一种新的软件开发的思想，这就导致了软件工程的产生，程序从一种按个人意图创造的“艺术品”，转变为一种工程化的产品。我们说工业上生产产品都有一个流程和模型，软件工程当然也不例外。它成熟的标志是60年代末软件工程的瀑布模型的提出。这个模型将软件开发的过程分为需求、分析、设计、开发和测试五个主要阶段。按照这个模型（当然还有别的模型），做完工程的每一个阶段，并不等于做工程。也就是说，虽然在艺术里添加了工程的思想，并不等于工程就会成功。似乎我们在原本的编程里添加了工程的思想之后，却忘了我们原本的初心是要实现工程，而不是一步步地按照模型将每个步骤操作一遍。工程很多时候被当作了借口，掩盖了我们做事情的真正目的。那些最初的前辈们，他们并不用什么工程，不也写出了程序，解决了问题吗？可是为什么如今讲工程了，讲过程了，讲方法了，却什么也做不出来了呢？工程只是一种实现的手段，让写出的程序更规范化而已，但是倘若只是一昧地遵循“工程应该这样做”、“工程应该那样做”，却不去考虑“项目要求这么做”或者“客户的本意是这样的”，最后项目失败了，那么岂不是得不偿失？
工程和组织最好分开来讲，项目经理在关注工程细节的同时还要关注人力资源、项目资金以及多个项目之间的协调等等。这些与工程本身并没有直接关系，而是“组织”方面的内容。这些都在试图说明一个项目经理必须有一部分甚至是绝大部分非技术性的工作。项目经理要建立计划，制定目标，培训员工，协调工作，准备资源，决定项目某个环节的的进度，还要经常开会来总结、激励甚至是惩罚员工，还不能盲目乐观。如果你做不到这些，你很有可能会犯错误，然后失去员工的信任，接下来等待着你的就是收拾东西走人。
BOSS是公司的经营者，他和工程基本上没有联系。文章中这句话很形象：公司的大小股东是“经营者”，董事会通常是解决经营问题的地方；而总经理、执行经理以及各个部门经理则是各级的“组织 者”，经理办公会则是解决组织问题的地方。
BOSS(经营者)决定了一个方向，组织者保证决策与这个方向是同步的，而工程是在这样的一个方向、决策的构架下的一个具体行为。工程中没有BOSS。工程不是做的，是组织的。不是有了模型，有了项目经理和开发人员，大家按照模型去做就可以成功的，这又不是煮饭烧菜，有原料人手和菜谱就可以的。这需要项目经理起好领头人的作用，组织这个工程中的各个角色，了解每一个人的特点和所长，把他们分配到适合的位置上，进行弹性分工，让每个人的价值在团队中得到最大的发挥。（这在上一章有具体说明）组织好工程中的各个角色，使得大家分工明确，步调一致，才能共同完成好项目。