A little schizophrenic

I had a good time “enjoying” Adam Bien’s article titled Why some of the Java EE / J2EE projects are inefficient …or at least suboptimal, which gives twelve reasons some J2EE projects are inefficient. I’ve picked out several that I’ve encountered or caused myself.

• “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…
• 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?
• Developers are sometimes too extreme: either everything is overengineered with millions of patterns or best practices, or hacked down in “go to spaghetti” fashion
• HA, Clustering, etc. is used even for “guestbook-like” applications. Complexity rules!
• 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 :-))

Points two, three, and four are a little schizophrenic. We want our code and product to be robust and extensible so that a small change in input parameters doesn’t mean rewriting half of what we already have. Yet we curse the tools that help us do that, such as those layers, interfaces, design patterns, and piles of XML configuration. I think those points are taken to absurd extremes. Still, they give us the crucial idea. We always have to find the balance where our code and everything around it, such as configuration and deployment, are as complex as the situation demands and not a hair more.

Related articles

• (Dagblog 1.1.2008) — On complexity