Home » Uncategorized » Why J2EE projects fail?

Why J2EE projects fail?

Well, In this post, I am going back in time and re-posting what I had mentioned in my response at “Theserverside.com” on 15th June 2005. The discussion had started in the context of Rod Johnson’s presentation at Java Symposium on this topic. At TSS  people around the globe shared their point of views on “Why J2EE projects fail?” and here is what I had mentioned then…. After 8+ years, do you think this list is still valid?

——————————————————————-

(http://www.theserverside.com/news/thread.tss?thread_id=34532#174389)

Thanks Rod and all for sharing your views on this important topic.

With my experience so far in the IT field, I have seen good number of projects failing (not only in just J2EE field) but also seen good number of them succeeding in big way.

I think here are the important factors which affect the success or failure of J2EE or any software projects. (Few of them are covered by Rod in his presentation)

1. Gap between Business Analysts and Technical Architects: Business Analysts need to translate the business requirements in simple language which can be clearly understood by the Technical Architects. On the other hand, the Technical Architects need to have some understanding on the business domain. Both of them can come up with simple glossary documents covering ‘Business Terminology’ and ‘Technical Terminology’ which will help them to understand what the other person is talking.

2. Missing Non Functional Requirements: J2EE may not help in achieving NFRs in the end. Yes, few parameters can be tuned to achieve few of the NFR goals. Critical NFRs must be clearly understood in the initial stages and should be considered in the Architecture / Design / implementation / QA-Testing stages. Project is considered as failure when the NFRs are missed by huge margins.

3. Architects role: Technical Architect plays a major role in overall application success. Architect needs to put the application building blocks in place by considering NFRs, possible appropriate J2EE technologies, etc. Architect should evaluate multiple possible options before settling on any one approach including partitioning of application / technology choice (J2EE != EJB) / communication protocols, etc. Architect should deliver detailed architecture and design documents well in advance which can be reviewed and discussed with senior members of team

4. Understanding of J2EE technologies: Not everybody from the development team is J2EE expert. Few of the members may be new to J2EE and needs to gear / brush up J2EE skills. Simple crash course on the project specific technologies and J2EE best practices will definitely help before the actual development starts.

5. Ongoing code review: The ongoing code reviews will help to verify that standard J2EE best practices are in place, design patterns are implemented correctly, coding standards are followed throughout the application, etc.

6. Use of productivity tools: Project teams should incorporate productivity tools in their development environment. These tools can include XDoclet, Checkstyle, PMD, Jalopy, etc. The team should have standard development IDE and build system in place.

7. Continuous testing and QA: Iterative and incremental development will achieve continuous testing and QA of deliverables. Standard bug tracking system should be in place and quality champions should track the overall progress with respect to quality. Application developer should spend time on unit testing. JUnit kind of unit testing frameworks should be made mandatory in project.

8. Adherence to J2EE specifications: Project teams need to stick to J2EE specifications and not to the underlying container specific APIs. These APIs are good in short term but in long term they will act as trap and you will loose WORA facility guaranteed by Java / J2EE.

9. Simple but working approach: Client needs working solution not the big technology stack. Over-designing the applications will not only take more time but will increase the chances of failure. Client requirements can be broken down in small sub systems and releases should be planned in such a way that client will get started on the application early. Even in small blocks when client see the working system, his and development team’s confidence will go up and obviously the chances of success will go high.

10. Use of Open Source components: Do not build everything on your own. There are several J2EE related open source technologies available on web. Use them (after evaluation and testing obviously) wherever possible. You can also modify them if needed for your application needs. This will help in saving development time. For example, displaytag utility can be used as navigational component.

Obviously this list is not complete. Keep posting your views on this.

Thanks
-Swarraj.

—————————————————————————-
Note: All these blog posts and views mentioned in my personal blog are my own and NOT of my current and previous employers. I am NOT representing any of my organizations through this blog. This blog is just for sharing my personal views based on publicly available information related to interesting things happening in Technology area.

Advertisements

4 Comments

  1. Venki says:

    Hi Swarraj,

    J2EE application design and development has matured over the years. But proper use of productivity tools, continuous QA and testing (especially unit testing) and adherence to J2EE specification is still area that needs to be improved.

    Above all these, most important one which is still a concern is “Gap between Business Analysts and Technical Architects”, which is why most of projects fail. I will quote very simple scenario here: “IT came up with some non-functional requirements to kick start overall requirement process. It had a requirement for “concurrent updates”, which was interpreted by business as “to view delta changes done by user 1 when viewed by user 2 before the changes were approved by team lead”. But IT team meant “two users updating the same data at same time”. Hence defining proper project nomenclature is key to success of any project

  2. jrkrish says:

    Swarraj, this is very well outlined. I believe that the greatest strength of J2EE is the specification based development, developers I work across different J2EE projects ask me how Iam able to develop good code consistently and have lot of knowledge in J2EE, answer is very simple – I have a great habit to read most of the JEE specification repeatedly and always tried to understand it more.
    Also the point you mentioned about NFR is very critical to the success of the project that is what separate men from boys.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: