引文：Why some of Java EE projects are inefficient

http://www.adam-bien.com/roller/abien/entry/why_some_of_the_java

Why some of the Java EE / J2EE projects are inefficient ...or at least suboptimal

Architects are more skilled in PowerPoint, than popular Java IDEs (OpenOffice ist still rare in real world :-))

It takes several DVDs, sometimes hours, even to install the basic infrastructure (like appserver and database)

Some popular servers take several minutes to start and deploy - you have to repeat this procedure several times a day

It takes longer to open a case (and reproduce a problem) for a bug of the appserver, than fix it by yourself (of course if you had the source :-))
It is hard to find developer hardware, where the "enterprise" development tools run efficienlty - ...and because they were expensive, it is hard to get rid of them...

The architects love layers and tiers - several mapping procedures are needed just to pass a persistent entity from the persistent layer to the presentation
Everything is configurable, replaceable and mockable. The XML overhead is huge. The question is: When did you really needed to replace something in your passed projects?
Either it is waterfallish, or agile with all buzzwords and strange rituals. Both sides could be extremely inefficent. It seems like sometimes it is hard to be just rationale...
Developers are sometimes too extreme: either everything is overengineered with millions of patterns or best practices, or hacked down in "go to spaghetti" fashion
"The thrill is gone..." many developers, architects and managers just lost they enthusiasm and passion. This is one of the main reasons, why many projects are just so inefficient...
HA, Clustering, etc. is used even for "guestbook-like" applications. Complexity rules!
Strange QA rules (like documenting obvious getters/setters) drive the development and maintenance costs


Just my observation hacked down in 2 minutes in Starbuck/Munich :-) What's your favorite? Do I missed something?