Top ten ways to create a real J2EE disaster

I have been just heard and enjoyed the Cameron Purdy's JavaOne presentation Top The Top Ten Ways to Botch an Enterprise Java Technology-based Application thanks to the JavaOne multimedia sessions.

It was a pretty good presentation indeed, and a great source for better practices and useful architecting advices -ok, I'm not sure if I got this feeling because the presentation was done on a negative approach, you now maybe I'm one of those people thinking Hey, I would never do that :-), but the fact is that it worked, it was a brilliant presentation.

This could be a brief summary:

• #10 Specifying the mechanism for data access without understanding the granularity of the data model


• #9 Assuming the container will take care of transactions


• #8 Using a stateless architecture


• #7 Designing the application for deployment on a single server and leave scalability and realibility up to the container


• #6 Utilizing popular technologies such as Web Services for component integration and remoting


• #5 Rolling your own frameworks


• #4 Distributing synchronous object graphs across servers


• #3 Designing logic and data flows assuming the application is a single-user system


• #2 Compensating for a lack of knowledge of the application domain by building in systemic flexibility


• #1 Putting off system testing until the application is ready to deploy

So, this is a pretty good list. mmmm I think I would never do that... lie... I must recognize that I felt over some of those points at some time, I think that everybody did it, and that's nice, that's what we call... experience :)