从总体上来说，构成目前J2EE 企业开发效率低下的原因有这么几个：分工过细，技术路线多头并进，客户无法参与，开发的复杂度太高。这几个方面的因素之间互为因果，相互作用，最后把整个开发过程拖入泥沼之中。下面详细论述。
5.1分工过细
J2EE的整个理论体系，来自IBM这样的商业化巨头，因此他们提出的技术架构，整体上遵循的原则，就是强化分工，强化分层。把原本是属于一个整体的应用系统，生生切分成用户界面层，应用逻辑层，数据访问层，数据存储层多个不同层次，并且在每个不同层次上再进行不断细化，将分工的特性发挥到了极致。这种分工方式在学术上也许是不错的范例，但在实际的项目开发中，严格的分工就必然意味着多工种，多层次的人员沟通和协调。在实际工作中，工作究竟应该切分到那个层次来完成，是一个妥协的结果，而不是单纯依赖学术探讨可以得出结论的。
采用J2EE以后，无意中就会接受这种分工的工作模式和工作模型，并且默认按照这种模式来组建开发团队，于是开发团队就开始膨胀，有前台开发的，有后台开发的，再加上数据库开发的，加上测试，项目经理光协调这么多人的工作都快忙不过来了，又那里有时间和精力来真正考虑一下项目的架构优化。
分工过细带来的另一个负面效果，就是很多人一开始就只能局限在自己的一个工作岗位上，对其他人的工作缺乏真正的认知，项目组成员里面，除了项目经理以外，几乎没有机会真正掌握整个系统的整体概念，因此在思考问题的时候，无法超越本身角色的限制，只能就事论事。在整个项目角度来看，几乎每个人都在盲人摸象，没有整体概念，项目的很多问题都被掩盖起来，到了最后关头才集中爆发出来。
在软件工程的观点中，适度的信息屏蔽可以减少无效信息对工作人员的干扰，以提高其工作效率和判断能力；但当这种观点走向极致，试图把每个工作人员都当成只关心一点的机械装置以后，整个项目组就变得极为机械，因为没法掌握整体上的信息，也无法真正从整体上对项目本身进行自省和改进。整个项目组很快就会陷入一种集体无意识之中。
5.2技术路线多头并进
技术路线的问题和分工过细的问题有很强的联系。正因为分工被强化和强调了，不同岗位，不同角色的工作人员自然采用不同的技术路线来试图解决问题，并逐渐发展出自己的一套技术路线出来。例如前端开发使用的是HTML语言，后来发展出CSS,JavaScript，而JavaScript又自己发展出若干套不同版本，适应不同浏览器环境的框架平台出来；而在后台开发的Java语言，先是发展出了JSP的标签库，又发展出JSTL，有了WebWork，又发展出Struts，又发展出Spring；和数据库交互访问的地方，有了Hibernate，又有了itabits等等之类；与此同时，又发展出log4j, 缓存工具等多种东西出来。
之所以发展出这么多新东西出来，原因之一就是强化分工以后，每个人都在试图解决自己面临的问题的时候，按照自己的思路提出了一个新东西，然后逐步发展，于是一个一个新东西就出现了。
这些新技术，新框架的出现，一方面确实简化了某一部分的开发工作，另一方面，从整个项目开发的角度来看，使用的技术越多，项目本身也变得越来越混乱，开发和维护的隐性成本在不知不觉中在迅速增加。
Spring的出现就是这种情况的一个很好的注解，因为开发中使用的东西太多了，不好配置，于是Spring的发明人想了一个办法，把所有这些东西打了个大包，装在一起，起了个大名叫Spring。但坦率的讲，这么做真的可以简化整个项目的开发吗，我非常怀疑。
5.3开发维护复杂度太高
开发维护的复杂度问题，与分工过细，技术路线多头并进又是互为因果的一个因素。当分工越来越细，越来越琐碎，使用的技术越来越多，使用者只能大概有个了解的情况下，整个系统的开发复杂度增加了，需要懂很多技术知识的人组合起来才能完成一个项目；从维护的角度来看，维护的人员也必须懂得这么多技术知识，才能保证系统的长期稳定运行。
开发的时候分工太细，使用的技术过多，最终必然导致开发和维护的复杂度增加，必然导致开发维护的成本居高不下。
然而不行的是，许多人面对这种问题的时候，本能的第一反应是继续强化分工，试图投入更多的人力来解决这一问题，却忽略了分工过细本身就是这个问题的一部分，在试图解决问题的同时反而强化了这一问题。
5.4客户无法参与
由于J2EE整个开发模式的设计，没有考虑客户该如何参与，如何提出自己的意见。详细的分析请见上面章节的分析。
同时，在一个如此复杂的开发环境中，开发人员自己都无法从整体上描述开发整体过程，开发的整体结构，在这种情况下，客户本身更加无法介入开发的整个过程之中，而只能在程序开发完成以后再提出意见进行修改。
从用户的需求到最终的程序实现，在一个复杂的开发流程中，需要消耗很长的时间才能完成，在此过程中，客户是无法参与的。而对最终程序的修改意见，又将使项目的开发进入新的一轮变动之中，从而进一步拉长项目的周期。最后所有人都疲惫不堪。