Sunday, November 21, 2010

Why the saying "If all you have is a hammer then everything looks like a nail" is so true in the IT industry

"If all you have is a hammer then everything looks like a nail" - Now do not ask me who quoted this or from where i found it.. I vaguely remember seeing it on one of my buddies gtalk status some time back. But the reality of this statement struck me a week back.

We had got this new project in our company. Not a major high scale project. But involved some calculations. Was very interesting. Our company has a few frameworks developed around the years which is used as best practice for many projects. When our architect got this project he without even considering the architectural perspective of the project put in an already existing framework to start development.

Note that this was a project that involved just two(three including the login page) pages. But the technologies included in the framework were as follows;
  1. EJB 3.0
  2. JMS
  3. Spring
  4. Hibernate
  5. Freemarker
  6. Jasper
  7. Struts 2.0
and a few others which i cannot recall at this moment. And i was thinking to my self from all these what we actually needed to do this project. And this was all bundled up into an EAR which came to a size of a thumping 30MB :S... I was amazed at why such a person with so many years of experience would go for such an inappropriate solutions. Of course looking at it from his perspective im sure the higher management would have given him ridiculously tight dead lines to finish the project which lead him into jumping to an existing framework. And also this project was under a maven build. I mean come on, to build a freaking 3 page module it takes around 2mins because of all the dependent modules existing in the framework which is almost always never ever going to be used within this project. Talk about time waste.

In my opinion my technology stack for this project would have been using a simple ANT build using Spring to wire up and handle transactions with Hibernate and struts to handle the mediation layer and bundle it up as a WAR. Ofcourse some time back i did a solution where all the commonly used JARs were bundled up in a single jar which was deployed only once(Note that we use JBoss A/S as our application servers). This is because if you really look at it, the project it self is only a few MBs of size. But what takes most of the space is the third party libraries we use. This solution lead to lesser deployment time because else it takes alot of time to do a remote deployment to the servers if the file size is large.

The fact lies with why we cant think beyond what already exists. To think the same framework works in all situations is like thinking one antibiotic will cure all viruses. Of course time lines are an essential component. But if you really look at it, using the right tool for the right job will help you finish up the job with time to spare rather than using an existing framework and removing all parts which you do not need which is both time consuming and error prone. 

So my theory is dont have just a hammer, but have a tool kit with various options under your belt which will serve you and your team mates better where by will be better for your company as well.

20 comments:

  1. 100% Ack.
    I'd like to add that IMHO and after working with a couple of languages in various environments that 'the Java people'really have a strong tendency to over-engineer, over-tool and oversize.
    Once you try to develop real! lightweight solutions, you have to leave the 'Java World', at least if you wonna get paid for your work.

    ReplyDelete
  2. Lol. Architectural Mishaps is really the right label for this. All too common, unfortunately.

    ReplyDelete
  3. Welcome to the world of Software development horseshit my man.

    ReplyDelete
  4. That happens in all industries. You've got traffic engineers who only know how to build freeways. You've got politicians who only know how to cut taxes. You've got musicians who think you can only make music with two guitar players, a drummer, and a singer. I'm sure the list could be extended indefinitely.

    ReplyDelete
  5. Antibiotics don't cure viruses.

    ReplyDelete
  6. hahah sry mate.. jst cldnt come up with a better metaphor :D

    ReplyDelete
  7. Hi Guys Thx for leaving by your valuable comments.
    @Paul - But dnt you think as an architect he/she must look at all options and have at least an exposure to some varying technologies without jumping into things straight away? Thx again for all your comments.Appreciate it.

    ReplyDelete
  8. Im sure this project probably took about 6 months to complete, with endless maven problems, endless problems mapping the database to hibernate, and in general just endless annoying things that slowed the project down. Oh and not to forget, endless deploys and restart of j2ee servers. Oh boy have I been there. It's so annoying that some developers, and strangely enough always the LEAD developers, have a tendency to overcomplicate and basically ruin even the simplest of projects.
    And when you propose a more simpler solution, they stubbornly and mercylessly work against it.
    I'm sure the same project could have been finished in 2 weeks using PHP, grails or just jsp and simple sql.

    ReplyDelete
  9. Im sure this project probably took about 6 months to complete, with endless maven problems, endless problems mapping the database to hibernate, and in general just endless annoying things that slowed the project down. Oh and not to forget, endless deploys and restart of j2ee servers. Oh boy have I been there. It's so annoying that some developers, and strangely enough always the LEAD developers, have a tendency to overcomplicate and basically ruin even the simplest of projects.
    And when you propose a more simpler solution, they stubbornly and mercylessly work against it.
    I'm sure the same project could have been finished in 2 weeks using PHP, grails or just jsp and simple sql.

    ReplyDelete
  10. @Mikkel - So true. Couldnt have said it better my self... I mean for a simple project there is just no use of maven anyway. Could have done it with a simple ANT script. And the purpose of Maven is to be used in a multi module project which it will serve you better.. And yes your right, some ppl just love over complicating things.. they just dnt realise that sometimes the simple solutions is the best solution... Thx for taking the time to leave a comment...

    ReplyDelete
  11. I wouldn't even use Spring and Hibernate for such a tiny project. Two Servlets or JAX-RS resources with plain SQL could be a simple solution.

    ReplyDelete
  12. Yes that is true.. The thing is there is a notion of using pure JDBC is bad with some ppl. But its true of what you say, pure JDBC would have been the way to go...

    ReplyDelete
  13. I dont see a problem with the approach used really.

    1) Does the code need to be optimized?
    2) How long did it take to develop?

    It is entirely possible that there was no need whatsoever for optimization in this case, and it is ALSO possible that whoever did this was so at home with the technologies that it was done faster than it would have been in a more lightweight-way.

    What Im saying is if you have knowledge and frameworks that you know how to efficiently use, there is good reason to try and benefit from those frameworks, both technology and knowledge-wise.

    ReplyDelete
  14. Hi Sandos,

    Actually the real problem is the fact that using a pre existing framework is good if its a large scale project.. here we are talking about just few pages.. thats it... to have to build multiple modules just to get an app with three pages of logic into deployment is just a waste of time IMO... and the prob arise when doing a remote deployment.. think of copying a 30MB EAR which is at the end of the day just 3 pages.. it took around 1hr to copy this... utter waste of time... n technology should be applied correctly at for the right scale project.. for a small scale project using all these technologies just doesnt make any sense what so ever as i see it... Thx for sharing your view point....Its all about choosing the right technology stack for the right project IMO...

    ReplyDelete
  15. 99% Ack. But i'm sorry, a maven pom.xml is far more simple than Ant Script.

    ReplyDelete
  16. true that a pom.xml is easy.. but dnt you think maven is much more suited if you are dealing with mid-large scale projects involving multiple modules? Thx for leaving a comment... Cheers

    ReplyDelete
  17. If you take the 'always evaluate new technologies' approach, you'll end up wasting a ton of time reinventing the wheel. If you make something really quick and dirty (like just slapping together a couple of servlets with some jdbc), it'll probably be a maintenance nightmare if the project is successful. How many times do developers slap together a POC only to have it be the end product (because the business wants it right then)? Then the developer is super pissed because they "never had time to get it right."

    If you have the build process, the deployment process, and software stack standardized, you are saving a ton of time (money) in training, resource management, and maintenance. If you use a stack that is designed for scalability, then you can scale up a lot more easily than if you had slapped together something.

    ReplyDelete
  18. Hi Matt,
    Thx for your valuable feedback.... You are true with what you say.. but i was not emphasizing about 'always evaluate new technologies'.. i was just saying to use the right framework(if there was any) for the right project.. you should look at scalability and all depending on the project your working on right? otherwise it will just be over engineering....

    ReplyDelete
  19. I closely work with an architect for around more than 2 years and on projects which seems to be very small in scale but at final integration time those project are going to be part of big project and all those small small projects have same platform and its very easy to integrate them. Just try to get bigger and brighter picture not part of frame is available to you. if project is so small then why need architect for it. :)

    ReplyDelete
  20. Thx for your comment... But this project was successfully completed without every increasing in scale so i highly doubt that :) .. And my point was that we should look into each aspect of the project. sure we cant judge all outcome but we should control what ever we are in control of.. specially the technology stack.. And as for my part, i am involved in the big picture and not limited to a frame :) cos i always look at a project from the big angle...

    ReplyDelete