Does Your Web Project Suck?
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.
- Login or register to post comments
- 5076 reads
- Printer-friendly version
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Rick Ross replied on Thu, 2008/03/27 - 7:01am
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
jordanz replied on Thu, 2008/03/27 - 2:14pm
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
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 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 replied on Thu, 2008/04/03 - 4:05pm
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.