Matthew is a DZone employee and has posted 155 posts at DZone. You can read more from them at their website. View Full User Profile

Does Your Web Project Suck?

03.27.2008
| 7466 views |
  • submit to reddit

Adam Bien has written a list of 12 reasons why some web projects may be inefficient. Does your curent web project have a case of ineffciency because of these?You can read Adam's 12 reasons over at his blog, but one that rang particularly true to me was this:

Everything is configurable, replaceable and mockable. The XML overhead is huge. The question is: When did you really needed to replace something in your past projects?

I've seen this pattern more and more lately with the insertion of Spring and other "modern" frameworks. If you're not careful, you end up with more XML than code! He's right, when did you actually need to replace the persistence layer in one of your projects? Aside from testing (which most people don't do formally with unit tests, I believe), have you ever replaced the entire persistence layer? For most people this would be a major, costly operation.

Another of Adam's things that rang true was his comment about layers. I see a lot of webapps trying to artificially insert layers. I'm guilty of it too, but there are times where simpler may actually be better :)

Do you agree with Adam's observations? Are there other reasons your webapp might suck? Share them here.

 

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

Comments

Rick Ross replied on Thu, 2008/03/27 - 7:01am

Well, I dunno. Since my job is to have my secretary get the requirements from the customers and take them down to the developers, I have to keep a positive outlook and be dimplomatic about things. I'm a people person, dammit! I can't be bothered about what the developers actually DO with the requirements! How the heck would I know if the web project sucks? I'm a people person, don't you understand? A PEOPLE person!!

Jason Marshall replied on Thu, 2008/03/27 - 12:40pm

One of my favorite architecture anecdotes is a propos here. I once had to talk a design team down from the proverbial ledge. At the end of a design brainstorm, I was asked to look at their whiteboard covered with sticky notes. I noticed something in the diagram that bothered me:

 

... code that does things - abstraction - abstraction - code that does other things - abstraction - database

 

I had to very calmly but firmly explaining to them that having two contiguous abstraction layers in their app did not improve the quality nor flexibility of the code. In the end the look of disappointment on their faces told me that they took it out just to shut me up.

 

 

 

Michael McDermott replied on Thu, 2008/03/27 - 1:00pm in response to: Rick Ross

Sounds like somebody has a case of the Mondays.

Jordan Zimmerman replied on Thu, 2008/03/27 - 2:14pm

I've seen this pattern more and more lately with the insertion of Spring and other "modern" frameworks. If you're not careful, you end up with more XML than code!

 Amen to that. What is going on in our industry? There seems to be a bizarre idea that writing code is bad. As it turns out, of course, code is code. Whether the file is named ".java" or ".xml" it's still code, it still has to be tested and maintained.

Alex(JAlexoid) ... replied on Thu, 2008/03/27 - 2:35pm

My personal best counter argument is:
   When was the last time you changed/added a column to a table in your database and got away with not rebuilding, restesting and redeploying your code? Even in RoR you have to retest+redeploy in most cases.

Jose Maria Arranz replied on Thu, 2008/03/27 - 4:54pm

 

 Common sense is not common these days. 

 We are living a paradox/contradiction:

  - Overengineering: promoted every day, people trying to convince us to test every stupid get/set method, isolate every piece of our program with mock objects for testing, trying to convince us about the beauty of some highly verbose and intrusive *architectural* frameworks.

  - In the same time scripting languages promoted to save the world with small code savings.

  An example of the current crazy:

  Imagine you want to offer a servlet to do some kind of web based service. Of course this servlet is already compiled and final ready to be deployed, but of course this servlet need some kind of configuration/listener registration. What is the typical path? an XML file!!  XML used to push data and to register LIVE objects. The result: tons of documentation about how to integrate this smart servlet with your code... oh I need to integrate with Spring... don't worry my XML format is now ready to call your beans defined in Spring XML... I need to integrate with X... I'm sorry is not supported by my XML format.

  The result: XML used as a poor-custom-meta-programming language.

  Question: Can I offer a base servlet? you only need to inherit your concrete servlet and setting up the service with my provided API inside the init() method, this way you can integrate with any thing easily.

  Current typical answer: but it isn't cool, is old, is boring, where is the XML? where are the annotations? calling Java methods? bah.

  We are losing the mind.

   Jose M. Arranz

   ItsNat Natural AJAX: 0% custom tags, 0% XML (is up to you), 0% view-metaprogramming, 0% code in the view.

 

 

 

 

Jim Karabatsos replied on Fri, 2008/03/28 - 12:58am

As a group, we seem to be absolutely enamoured with abstractions upon abstractions -- I blogged about this topic almost two years ago, in my article Too Many Levels of Abstraction if anyone is interested. 

Management summary -- some things are already abstractions by their very nature.

-- Jim

Joe Farmer replied on Thu, 2008/04/03 - 4:05pm

What I hate about this "modern" architecture is number of dependencies it creates. No project starts w/o having 200 commons,..., cannot-find-it-on-web.jar on the class path. People get lazy, if they need trim() function they will bring commons - "just in case" they need another string manipulation functionality.

Tiago Brito Spindola replied on Tue, 2008/04/08 - 5:15am

I don't agree with Adam Bien. I do appreciate the possibility to replace underline implementation when necessary. Of course the overuse of abstraction should be avoid, but if you program against interfaces you need a away to configure the application. It can be done with XML or directly in the Java code, the problem is to find the correct balance between both. If you would like to have a look how configuration and replacement of underline implementation can be achieved see my article (Spring In Small Doses) about development application with Spring.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.