相信从小我们遇到困难时耳熟能详的一句话叫做“失败乃成功之母”，也就是说做事情虽然失败了，但是我们能从失败中学到经验和教训，为成功奠定基础。
从50年代到60年代，人们曾经把程序设计看作一种人人发挥创造才能的技术领域，只要能得到正确的结果，程序的写法可以不受任何约束。人们认为好的程序应该是运用了许多与众不同的技巧和窍门的程序。这种观点就好像把编程当作了一种艺术，因为艺术总是宣扬个性，与众不同。然而，随着程序的规模越发地庞大，人们在实践中发现随心所欲编写的程序给后期的维护带来了很大的麻烦。程序晦涩难懂，不同时期，不同程序员写的模块难以接口，因此，软件开发遇到了很大的困难，往往投入很大，收效甚微，出现了软件危机。于是，人们在茫然之中，渐渐地抛弃了原有的观点，开始探索一种新的软件开发的思想，这就导致了软件工程的产生，程序从一种按个人意图创造的“艺术品”，转变为一种工程化的产品。我们说工业上生产产品都有一个流程和模型，软件工程当然也不例外。它成熟的标志是60年代末软件工程的瀑布模型的提出。这个模型将软件开发的过程分为需求、分析、设计、开发和测试五个主要阶段。按照这个模型（当然还有别的模型），做完工程的每一个阶段，并不等于做工程。也就是说，虽然在艺术里添加了工程的思想，并不等于工程就会成功。似乎我们在原本的编程里添加了工程的思想之后，却忘了我们原本的初心是要实现工程，而不是一步步地按照模型将每个步骤操作一遍。工程很多时候被当作了借口，掩盖了我们做事情的真正目的。那些最初的前辈们，他们并不用什么工程，不也写出了程序，解决了问题吗？可是为什么如今讲工程了，讲过程了，讲方法了，却什么也做不出来了呢？工程只是一种实现的手段，让写出的程序更规范化而已，但是倘若只是一昧地遵循“工程应该这样做”、“工程应该那样做”，却不去考虑“项目要求这么做”或者“客户的本意是这样的”，最后项目失败了，那么岂不是得不偿失？
工程不是做的，是组织的。不是有了模型，有了项目经理和开发人员，大家按照模型去做就可以成功的，这又不是煮饭烧菜，有原料人手和菜谱就可以的。这需要项目经理起好领头人的作用，组织这个工程中的各个角色，了解每一个人的特点和所长，把他们分配到适合的位置上，进行弹性分工，让每个人的价值在团队中得到最大的发挥。（这在上一章有具体说明）组织好工程中的各个角色，使得大家分工明确，步调一致，才能共同完成好项目。