J2EE project dangers!
Avoid these 10 J2EE dangers to ensure your enterprise Java project's success
In my various tenures as developer, senior developer, and architect, I have seen the good, the bad, and the ugly when it comes
to enterprise Java projects! When I ask myself what makes one project succeed and another fail, it is difficult to come up
with the perfect answer, as success proves difficult to define for all
software projects. J2EE projects are no exception. Instead, projects succeed or fail by varying degrees. In this article
I aim to take the top 10 dangers that affect the success of an enterprise Java project and showcase them for you, the reader.
Some of these dangers simply slow down the project, some are false trails, and still others can outright ruin any chance of
success. However, all are avoidable with good preparation, knowledge about the journey ahead, and local guides who know the
This article is simple in structure; I will cover each hazard as follows:
- Danger name: One-liner outlining the hazard
- Project phase: The project phase where the hazard occurs
- Project phase(s) affected: In a lot of cases, hazards can have a knock-on effect on later project phases
- Symptoms: Symptoms associated with this hazard
- Solution: Ways to avoid the hazard altogether and how to minimize its effects on your project
- Notes: Points I wish to impart that relate to the hazard, but don't fit into the previous categories
As noted above, we'll examine each danger in the context of an enterprise Java project, along with its important phases. The
project phases cover:
- Vendor Selection: The process of picking the best possible mix of tools before you start your J2EE project -- from the application server right
down to your brand of coffee.
- Design: In between a rigorous waterfall methodology and an approach of "code it and see," lies my take on design: I do enough design
so that I can move comfortably into development. I consider my design phase complete when I know exactly what I am building
and how I will build it. Moreover, I use design templates to make sure I have asked all the right questions of myself and
my proposed solution before moving into development. However, I'm not afraid to code in this phase; sometimes it's the only
way to answer a question on say, performance or modularity.
- Development: The project phase where the amount of work done in earlier phases will show. A good choice of tools coupled with a good design
doesn't always mean a super-smooth development, but it sure helps!
- Stabilization/Load Testing: In this phase, the system architect and project manager will impose a feature freeze and focus on build quality, as well
as ensure that the system's vital statistics -- number of concurrent users, failover scenarios, and so on -- can be met. However,
quality and performance should not be ignored until this phase. Indeed, you can't write poor-quality or slow code and leave
it until stabilization to fix.
- Live: This is not really a project phase, it's a date set in stone. This phase is all about preparation. It's where the ghosts
of past mistakes will come back to haunt your project, from bad design and development to a poor choice of vendors.
Figure 1 illustrates the project phases most affected by the different causes (and in particular the knock-on effects).