Adam Bien's Weblog
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?
Summer Workshops: From Java EE 7 Bootstrap and Effective Java EE 7 to Java EE 7 Architectures