除了软件本质力量的推动之外，商业因素也推动者软件工程体系的发展。大公司门的争夺战的最终结果，已经开始把软件工程，从原始的自生演进状态逐渐推动到它激发展的状态上了。
这种它激发展可能会影响到软件工程发展的速度，然而在各个工程层面上的关注点并不会发生变化。现在，我们从一个细节跳出来，来看看我们的角色。这个细节就是：如何完成今天的工作。正如前面所说，如果你是一个软件公司里的项目经理，你可能今天的工作是写一份计划方案，或者听测试部的报告，又或者是安排会议来听取和分析一个新的产品需求。然而我觉得这就是细节。细节就是你使用的Project 2003,或者你正在公司内部署和推光的ClearCase.如果他们正好是今天要完成的工作。蚂蚁的团队总是被本能得组织的很好。然而如果一个蚂蚁的群体中有了流行疾病，蚂蚁在死去，而新生蚂蚁不能跟上其死亡的速度，那么很快，这个团队就亏散了。
这是因为蚂蚁用于维护团队运作的资本在流逝。如果资本没了就能没了运作，团队的存在就没有了必要性和可能性。项目就死亡了。埋头与huagantute的项目经理犯下了与挖山不止的愚公类同的错误：忽略了成本。如果愚公真的成功，那么可能是300年后。然而如果一个工程要300年才能做成，那么在做成之前，客户就选择了放弃。如果有机会，项目经理可以选择向另一家公司购买一个产品来卖给客户，从为客户开发变成为客户定制，以及为客户服务。这样在没有任何开发成本的前提下完成了工程。与另一个极端的例子相比，你会发现他与第五章中那个做过场的项目全然不同。后者要做完了工程，却没有做成工程。而现在这个项目经理却做成了工程，却没有做成工程。而现在这个项目经理却做成了工程，但是在许多过程环节上，他根本就没有开始。然而现在，除了跃跃欲试的技术的经理外，没有人会不满意这个结果。技术经理最常说的话是我们可以开发出来开发人员最常说的话是我可以开发出来愚公最常说的话是何苦而不平？愚公如果停下来可能会想的问题是碎石的方法，而项目经理从细节里跳出来，思考的问题就应该相当于完成工程的方法评价这个方法的好坏标准只有一个：节余成本。我经常注意到的成本因素包括时间、人力、资金和客户成本。而大多数情况下，人们不会把客户的数量以及耐心当作客户成本来计算。而在我的项目规划中，这是成本。如果你仍旧不明白为什么会有这么多被神秘力量所驱动着的开发，那么你就干脆去厨房找个平底锅烧点热油，然后敲碎下一个鸡蛋，很快，你就体悟到以蛋黄驱动开发的真帝了。抛开实现的技术细节不论，在工程中，以什么驱动开发其实是一个过程问题。