J2EE project dangers!

Avoid these 10 J2EE dangers to ensure your enterprise Java project's success

1 2 3 Page 2
Page 2 of 3

Going live is a complicated process, as fraught with political issues as it is with technical ones. You will run into unexpected problems; that's what live is all about. Development and stabilization environments give you the room to make many mistakes and find these problems before going live! Use it, as that will remove most of the pain and risk from taking your application live.

The more projects you get under your belt, the more you will already know what works and what doesn't. Keep an engineering notebook for yourself and your peers. Your goal should be to never make the same mistake twice in going live.

Danger 5: Choosing the wrong vendors

Project phase:

Vendor Selection

Project phase(s) affected:

Design, Development, Stabilization/Load Testing, Live

System characteristics affected:

Scalability, performance, maintainability, stability

Symptoms:

  • Developers spending more time wrestling with tools than productively using them
  • Significant system redesign required in order to work around known or unknown bugs in the implementation
  • Poor or zero integration between different tools (application servers and IDEs, IDEs and debuggers, source control and build tools, the list goes on)
  • For IDEs, debuggers, etc., developers simply forsaking them in favor of their own favorite tools

Solution:

To avoid Danger 5, you need a good vendor selection process. Danger 10 is applicable here too.

For IDEs, the only way to really evaluate one is to use it. The only way to evaluate a J2EE implementation is to build a proof of concept that touches the features you are betting your architecture on. Indeed, you do not want to find a bug in the clustering implementation when you have already spent three months in development and invested in specific training.

What if, halfway through development, you have trouble with your toolset? Well, some tools prove more important than others. If your chosen application server inadequately meets your needs, you need to suck it up and change the specification. If the IDE stinks, set minimal levels around coding standards (tabs versus spaces and so on) and let the developers pick whatever makes them the most productive.

Notes:

Knowing the best vendor or tool for a particular task is not a "do once" job. You need to continually evaluate the market. For example, I have used four different IDEs in the past 12 months, depending on my application server, platform, and whether or not I was coding EJBs.

Danger 6: Not knowing your vendors

Project phase:

Vendor Selection

Project phase(s) affected:

All phases after Vendor Selection -- Design, Development, Stabilization/Load Testing, Live

System characteristics affected:

Maintainability, scalability, performance

Symptoms:

  • Development takes 33 percent longer than the worst estimate
  • Developers reinvent the wheel when the vendor or implementation provides the required functionality out of the box

Solution:

To avoid the dangers resulting from not knowing your vendors, subscribe to all the vendor-supplied support resources you can find such as email lists, news groups, and release notes (especially those with a list of bug fixes); you will get invaluable information.

Once you've picked your vendors, invest in training as soon as possible, ideally well before the project kicks off. Next, build a quick proof of concept to break the team in gently. Build a couple of EJBs and deploy them, then call to them from your presentation-layer technology (Swing GUI, JSPs, and so on). If you try to construct your development environment while concurrently trying to meet a project goal, the environment setup will always play second fiddle. Indeed, I have seen projects where there was never a build process in place because, "We didn't have time." That became even more profound when the team had to stay until 11:00 each night just to get the application together for a release to development. Therefore, take the time up front to nail this stuff down -- it will save huge amounts of time down the road. To those who say, "Our schedule doesn't give us the time," I reply, "Your schedule doesn't give you the time to not do it."

Notes:

How transferable are vendor-specific skills in the J2EE world? Let's look at a concrete example of how two vendors -- IBM and BEA Systems Inc. -- that support EJB 1.1 produce dissimilar application servers. Indeed, how alike are BEA WebLogic 5.1 and IBM WebSphere 3.5?

  1. BEA WebLogic is configured and administered in a completely different manner than IBM WebSphere.
  2. IBM adopted an all-GUI environment philosophy with WebSphere. In contrast, BEA provided a whole host of command line utilities with WebLogic.
  3. IBM WebSphere uses IIOP to communicate and throws CORBA exceptions that are visible to the programmer; WebLogic has no CORBA infrastructure at all, and uses the t3 protocol by default.
  4. WebSphere is joined at the hip with Visual Age, while WebLogic is more IDE-agnostic. Indeed, you can develop for WebLogic using almost any IDE.

These are just a few points of difference; many more exist. Bottom line: most vendors are as alike as chalk and cheese. Being an expert on one application server does not mean you are an expert on all. The arguments above apply to anything: IDEs, debuggers, build tools, configuration management, and so on. Having experience with a particular tool is a good thing that positions you to evaluate a competitor. However, it does not mean you can transition seamlessly from one product to another. As such, allow yourself the time required to be skilled with your tools.

Danger 7: Not designing for scalability or performance

Project phase:

Design

Project phase(s) affected:

Development, Load Testing, Live

System characteristics affected:

Scalability, performance, maintainability

Symptoms:

  • Unacceptably slow systems (that are not amenable to refactoring)
  • Systems that make heavy use of server-side state and cannot take full advantage of vendor clustering technology

Solution:

With Danger 7, close in on your performance and scalability requirements in the scoping phase -- know what numbers you need to hit before you move into development. If you know you need 50 transactions per second and your all-entity bean design will provide only 40, then you need to look at alternative solutions such as stored procedures, batch processes, or reworked OLTP aspects of your system.

Involve your vendor as much as possible in the scaling requirements -- they should know the strong and weak characteristics of their product and help you accordingly.

Notes:

Not designing for scalability or performance is often seen as a conflict to Danger 2 (over-engineering). In fact, they complement each other. My solution to Danger 2 advocates building only what is absolutely necessary. By addressing performance and scalability, you set an upper bound on what is necessary.

If you identify massive scalability as a key requirement, then you will first specify an application server with great clustering support, probably with a transactional cache underneath for performance. Further, you will engineer business objects as EJBs in order to take advantage of the server architecture. XP won't have a problem with this, you are still building only what is absolutely necessary.

I view this line of thinking as a method of providing checks and balances. While I want the simplest possible system, that system needs to provide the functionality and behavior required by the client.

Danger 8: Antiquated development processes

Project phase:

Development

Project phase(s) affected:

Stabilization, Live

System characteristics affected:

Maintenance, code quality

Symptoms:

  • A project plan that looks suspiciously like the waterfall method: "First we design the system from scratch, then we sit down and code it in one huge chunk of time."
  • Because a build process doesn't exist, builds are a nightmare.
  • Build days equal lost development days because nothing else gets done.
  • Components are not adequately tested before integration. Indeed, integration testing means taking two unstable components, strapping them together, then looking at the stack traces.

Solution:

A good software methodology will save your life. I've already mentioned XP; the Resources section below contains a link to the site. There you will find XP covered in great detail.

Notes:

I can't believe that I ever managed without JUnit for unit testing and Ant for building -- two free tools that underpin the XP methodology. For more on JUnit and Ant, see Resources.

Danger 9: Failure to employ frameworks

Project phase:

Development

Project phase(s) affected:

Development, Stabilization, Live

System characteristics affected:

Maintenance, extensibility, code quality

Symptoms:

  • Bugs in core libraries that are used multiple times in code.
  • No set logging standards -- so system output is impossible to read or parse with scripts.
  • Bad and inconsistent exception handling. At some sites I have seen, end users are exposed to low-level system errors, for example sending back a SQLException stack trace when a user tries to check out their shopping cart. What is the user going to do? Ring up the database administrator and request a fix on a primary key constraint?

The following tasks are handled in a myriad of ways by developers and should be among the first targets of any framework:

  • Logging
  • Exception handling
  • Getting a connection to a resource (database, naming service, and so on)
  • Building JSP pages
  • Data validation

Solution:

I am a huge believer in heavily used, lightweight frameworks. In fact, my first JavaWorld article -- "Frameworks Save the Day" -- discussed frameworks in enterprise Java environments. If you are already in development, you will still reap huge dividends by adopting a framework now. You will experience some pain in reworking tasks such as exception handling and logging, but in the long run it is time and money well spent.

Notes:

Think of different levels of reuse when it comes to frameworks and component-based development in general. The first level, plumbing, has a reuse factor of 0.9 or higher, which means 90 percent of projects will use it. The more specific the service, the lower the reuse factor. That is, I might build an accounting service to manage resource usage and expect to use it on 50 percent of projects. But for those projects that need it -- boy, are the developers ever glad it's there!

Danger 10: Basing project plans and designs on marketing blurb, not on technical fact

Note: Danger 10 didn't appear on my list, until I realized that many more people than I thought harbor serious misunderstandings about enterprise Java, particularly new arrivals to the field.

Project phase:

All phases are affected, with Vendor Selection particularly influenced

Project phase(s) affected:

All phases are affected

System characteristics affected:

Maintenance, extensibility, design quality, code quality

Symptoms:

  • Technical decisions taken lightly because EJBs are designed to be portable
  • Vendor selection performed without a "hands-on" trial of the product
  • Needing to switch tools during a project lifecycle

Solution:

Don't believe anyone with a vested interest outside of your project. This means: don't believe vendors (unless you know them already) and don't believe white papers paid for by vendors. If you want some real-world advice on application servers, check out the reviews links in Resources. Going further, download the tool you want to evaluate, roll up your sleeves, and prototype with it. Run through the examples provided (any good vendor will have these).

To sum up, selecting the right vendor and toolset for your project takes time, time you probably don't have. Narrow down your selection to three to four choices, then take them for a drive. Build a weeklong proof of concept using your initial choices of application server, IDE, build process, and so on. Be comfortable that you can do what the development plan calls for with the tools you have.

Notes:

If you are short on J2EE expertise, that will hurt you most in the initial stages of your project. Decisions made at the beginning produce huge knock-on impacts on the overall success of the project. A good J2EE consultant will be able to run a great vendor selection process and leave you in great shape moving into design and development.

Just 10 dangers to worry about?

Ten is an arbitrary number that serves as a cutoff point -- numerous other dangers exist. Indeed, I know of a couple more myself. But even so, if you address the ones listed here, I guarantee you that your project will be in excellent shape and positioned to succeed.

If there is one thing that I urge you to take away from reading this article it is this: There is no substitute for experience and planning. If you don't have experience, get it. Don't bet on on-the-go training for yourself or your team during a project. Be proactive and source it before development, ideally before design commences. Seed your team with Java and J2EE mentors to act as guides for the project's overall direction and make sure that they grow other, less experienced team members along the way.

Finally, the more I wrote, the more I realized I also want to talk about:

  • Social aspects of software engineering
  • Unit testing versus integration testing (when is testing done?)
  • Design patterns
  • Exception handling

Alas, I just don't have room. Perhaps another article soon. Anyway, good luck!

Conclusion

Well, there it is. The top 10 dangers that, taken together, are responsible for most if not all of the problems you will face or have already encountered in enterprise Java development. I am certain that other pitfalls await you on your journey, but I believe that I have covered the main ones. Just to recap, below are the top 10 dangers ordered according to priority:

1 2 3 Page 2
Page 2 of 3