作者首先讲的是编程时对于语言的认识，作者在第一章时就说过，成天讨论这门语言好，或者那门语言坏的人，甚至是可悲的，对于一个程序员，或者以程序员自命的人来说，看清楚软件编程的第一步，就是一句“语言只是工具”。
作者在这张图中阐述了代码、方法、过程、与组织的关系，在最内层的环中是编程的本源定义，是最原始的状态，与代码相关的任何工作最终都回落足于这样一条规则。推动这种逻辑向前发展的，是“方法”和“方法论”的出现。长期的编程实践，自然的归演与总结，必须沉淀为某种（软件开发）方法，于是“过程”出现了，”“对象”出现了，于是相关的方法论也就出现了。这是实践的成果，方法并不是由某个人或某个组织创造的，是实践积累的结果。只有从不断的实践中才能总结经验和方法，经验来源于回顾、理解与分析，而不是你将要写的下一行代码。
过程半生工程而出现，过程解决的是工程中角色间的关系问题。
过程说的是很多人如何组织在一起进行开发的问题。他首先八工程中的环节分解出来，这样有了环节，就有了角色，有了角色，就有了沟通。因此过程中的问题，就是角色、沟通和环节的问题。环节重要取决于具体的编程行为，也就是具体项目，对于产品来说，更重要的是品质和技术壁垒，但是用这样的模式去做项目，客户只会看到他们因为项目的一再延迟二而恼怒。作为一个项目经理，这是可怕的，因为他不能分清那个环节更加重要。
最狭义的工程，是描述“做什么”和“做到什么”。 也就是说，是对目标的描述和成果的检测。至于这个工程目标的实现，是“过程”和“方法”的事；而有效、快速地实现“过程”和“方法”所需的，就是“工具”。过程伴随工程而出现，解决的是工程中“步调一致”的协作问题。而工程的出现根本原因是软件规模的不断增大，以及项目的“复杂”，要求不同的知识领域的角色参与，一个人是难以胜任的，要求更多的资源。“团队”作为开发行为的模式，是软件规模和复杂度渐次累积的结果。团队必将越来越庞大，因为软件规模必将越来越复杂。没有团队意识的软件公司将在高度过程化、通晓方法理论、拥有大量工具的集团军面前必将一触即溃。工程理论其实是包含组织学的，在上面图中可以看到，周爱民先生将组织与工程分离开，并在而这之间画下了一道纵向的线。如果作为一个项目经理，你必须有一部分的工作时非技术性的，你必须更加关注工程的组织与计划，站在“组织者”这个角度上看待问题。
从最初的简单编程开始，到现在工程团队的组织开发，实现( 一个软件) 都是最终的目的。所以可以这样说：实现，是软件开发的本质需求。