EJB programming & troubleshooting: Managing J2EE Project Observations and Request For Comment

  1. I am a project manager for a modest enterprise. It is my observation that J2EE developers for small apps ( less than 1000 users) have low productivity.

    We use WebLogic 6/7, Oracle/DB2 and JBuilder7. Assuming that my team members are top notch J2EE code jocks, it seems that CMP usage drags productivity down the drain. Tasks that take days with direct JDBC become weeks under CMP.

    It seems that the learning curve is to steep for small teams (1-3 developers).

    Do others observe this ?
  2. Hi,

    By J2EE I assume you are talking about the learning curve/cliff associate with EJB development. I agree that for small projects EJBs are overkill and cause increased development time. This time has been decreased with tools like XDoclet and ANT but it still exists.

    On a side note when the dot com bubble burst there were quite a few reports from large companies talking about the increased cost of development. From what I remember most of the issue revolved around the fact no matter what the project was EJBs were mandated.

  3. Well, the number of users isn't really a good metric for appropriateness of J2EE. You'd need something like project complexity. I just finished working on a project targeted at 15-20 users total, that used J2EE and used EJB, but used JDBC instead of entity beans. I can say that if we had gone with Entity beans and CMP I think things would've been quicker, but it all depends on what you are doing. If you just want to get access to domain obejcts and get persistence implemented simply, CMP is a real time saver. The alternative is to write all kinds of the exact same JDBC code for each domain object you want to persist, or to roll your own persistence framework, which is ultimately not gonna save you much time over CMP.

    For someone who has not used a particular J2EE technology (and CMP is probably the most complicated thing to get working), yeah, I'd agree the learning curve can be steep, but the other problem that I've noticed is that you get a really good J2EE developer and he wants to use every part of the app server, even if it isn't warranted. That can hit your productivity. Or, you get a developer that wants to roll their own uber-framework because they don't like the way something in J2EE works.

    But, back to CMP, my experience from doing CMP is that it is a hell of a lot less work than doing your own JDBC thing, mostly because the amount of code and XML that needs writing is less, and you don't have to spend as long testing it because you are depending on the app server for a lot. Usually, once you deploy an entity bean, you can just write a basic test case to verify you configured everything right and that's the end of it.

    What were the issues the team faced that caused such low productivity? I can see if learning CMP for the first time was it, as the docs (especially for relationships) with weblogic and the DTD are very weak.

    Also, keep in mind that development time isn't a measure of product quality. YOu could probably hack out something in PERL much quicker than with J2EE, but would want to maintain that or sell it to clients?
  4. George,

    The learning curve is somewhat steep. However, it also depends on some other factors. The learning curve on Weblogic is also quite steep. Much steeper than lighter app-servers like Orion or JRun.

    It also depends on your development environment, standards, and quite frankly you. I've worked on both the management side and the development side for J2EE and other development environment projects. Also, what are the goals? So let's get into that.

    1. Development environment: I found (anecdotally) that when I switched from JBuilder Enterprise recently to the latest build of IDEA's Intellij(Ariadna) 3.0, my productivity went way up. It used to take me at least 4 or 5 minutes just to get all of the framework setup for my EJB. Now I can do it in about 30 seconds with Intellij. That may just be that I work better in that environment though. There are probably others out there that are even better.

    2) Weblogic can be a real gorilla sometimes. It's a great enterprise system, but for development it has it's own learning curve, it can take a lot of work and development time. My company requires a pretty complete level of portability among app-servers. Because of that, I do all of my initial development on JBoss or JRun 4.0. Then I test on others as I need to. I've found that the time I save using these app-servers for development more than makes up for the time that I need to spend doing portability checks and writing app-server specific deployers (although that does to some extend depend on the complexity of the server specific files).

    3) Goals: If you are simply looking for output productivity in terms of releases and a working system, you should probably try using Cold Fusion (which is now based on J2EE anyway, and will run on your Weblogic server). If you want advanced architectures, n-tier, caching, EJB's, whatever, you're gonna go a bit slower, but your app will likely be more robust (assuming, as you say, that these guys are top notch).

    4) Are you guys using a framework? or developing everything yourselves? Fameworks can eliminate a lot of the infrastructural things that you would normally have to develop yourself.

    5)And last: You. I've managed projects and understand some of the frustrations that you are seeing. However, military units have an expression: "There's no such thing as a bad team, only a bad leader." You're management and leadership will be as important in the productivity as the learning curve on EJB's. I try to make sure that I'm not the problem before I decide that something technical _is_ the problem. That way I get to review my management style, but it (hopefully, but not always) eliminates me as the problem. Then you can be sure that the problem is technical, and you can work on the bottlenecks.

    One more thing that I've found useful for managing programming projects is a direct application of the "Theory of Constraints" proposed by Eliyahu Goldratt. You might buy and read a book called "The Goal" by that Goldratt. The Constraints is easily applicable to programming models, and it might help you identify the problem and deal with it.

    Jason McKerr
    Northwest Alliance for Computational Science and Engineering