In this talk, Rod drew on his experience as a consultant to discuss why J2EE projects often fail, and how to avoid common pitfalls. The main focus was on technical issues, such as architectural choices and coding practices. Rod also discussed organization issues such as approaches to team management and tool set, and process issues such as appropriate risk mitigation and testing strategy. The presentation concluded with positive recommendations that may help to make your projects more successful.

Watch Why J2EE Projects Fails

to discuss why J2EE projects often fail

It seems to suggest as if J2EE projects fail more often than not. Is it really the case? I don't think so!

The presentation does not work for me, neither in explorer nor firefox. Is there a text-based presentation?
Anyway, I do not think J2EE projects have something special, the problems in project management will be the same than other type of projects.

Joserra
Modelos de Negocio basados en Software libre. Najaraba.com

Just be patient... it takes some time to load ;)

If you see a broken image, then you need to install flash. If you see a blank white page, then you need to wait (the UI is downloading).

I've been on several J2EE projects and they do fail. When it happens it's usually a combination of several things: developers not doing their homework, poor management, etc.

Of course none of this should surprise anyone reading this. I think one of the best ways to scuttle a project is to put people with the wrong skillset into senior positions and then let them set direction without doing any homework in the givin problem's domain.

-- my .02$.

Coming from a .NET background, I think projects fail regardless what technology is used. The most important factor in determining success or failure of a project is in my opinion, the management, I believe in a pretty strict programming environment, I don't believe that developers should be doing stuffs on their own, using the OS of their preference and adopting their own coding style or IDEs.

Yes, I believe in coding fascism

I agree, it doesen't matter what is used J2EE/.net.
All you need is a quality asurance system that reflects customer requirements through the whole development process.
Such systems should interact dynamically and identify things like performance problems before you even start to think about the solution. Well, most J2EE products outthere are bananas that maturate on the customer side. You buy them green and one day they turn yellow or brown ;-).

[quote]I don't believe that developers should be doing stuffs on their own, using the OS of their preference and adopting their own coding style or IDEs.[/quote]

I really don't see how the choice of IDE would cause a project to fail. In my opinion if developers can decide the IDE then they will be more productive and happy. Ofcourse i can learn to use a new IDE and be as producive after some time (unless the IDE sucks)... but if I don't like the IDE i wont be happy.

I really don't see how the choice of IDE would cause a project to fail. In my opinion if developers can decide the IDE then they will be more productive and happy. Ofcourse i can learn to use a new IDE and be as producive after some time (unless the IDE sucks)... but if I don't like the IDE i wont be happy.

It will take a couple of days for any developer to be productive in any widely accepted IDE nowdays.

However, to maintain project integrity there should be one way to set up a project (hence one IDE), one way to write code (coding guidelines), and of course one Opearating System.

Otherwise, you end up with a Zoo where code is unreadable and bugs happen in one environment and not the other.

--Dmitriy.

[blockquote]However, to maintain project integrity there should be one way to set up a project (hence one IDE), one way to write code (coding guidelines), and of course one Opearating System.

Otherwise, you end up with a Zoo where code is unreadable and bugs happen in one environment and not the other.
[/blockquote]

Coding guidelines can be followed no matter what IDE you use. If you're talking about the stucture of the code you can always reformat the code before It gets commited to CVS with some prettyprinter. It's probably still the same compiler. You can probably still set the same classpath's, Libraries,commandline arguments and so on... there is always ANT integration which could be used with the same settings across alot of different IDE's to compile,classpath, prettyprinter etc.

I agree with you on the OS issue.



I do agree with the one OS.. different JVM different problems.

But ok I can live with it if the standard IDE is IDEA :)

It will take a couple of days for any developer to be productive in any widely accepted IDE nowdays.

And possibly feel nausea.

However, to maintain project integrity there should be one way to set up a project (hence one IDE), one way to write code (coding guidelines), and of course one Opearating System.Otherwise, you end up with a Zoo where code is unreadable and bugs happen in one environment and not the other.--Dmitriy.

Absolutely disagree, reasons:
- only separate build server and build management guarantee project integrity; there should be no IDE specific whatsoever;
- when developers use different IDEs it helps:
-- keep developers happy;
-- guaranties that project is IDE agnostic;
-- helps having straightforward and well understood (and documentd) build/deploy process;
Same is applicable to OS, with Ant/Maven Java project can be pretty much OS independent and it is not that hard to maintain a bit if OS dependency if necessary. It actually may help streamlining and adressing such spots if team pays enough attention.

i can follow the line of argumentation that using different environments during development can help identify possible conflicting situations in producation later on.

but the j2ee-world is complex enough as it is - ever tried migrating applications from, say WebLogic to WebSphere?

and of course, i too have my favorite editor, ide, os, ... but think about wether a carpenter on a construction site would argue that using a hammer to hit nails does not make him altogether too happy, so he would like to resort to using screws. see you in the unemployment line

and of course, i too have my favorite editor, ide, os, ... but think about wether a carpenter on a construction site would argue that using a hammer to hit nails does not make him altogether too happy, so he would like to resort to using screws. see you in the unemployment line

IDE vs IDE is more like Hammer vs Hammer.

Hammer vs ScrewDriver is more like Java vs .Net.

good point - still, i don't think we're talking hammer vs hammer in J2EE IDE's... too many dependencies and such. quoting freely from an IBM Redbook regarding EJB development using WSAD:

"even thought it's possible for every developer to install the product to a unique path on their filesystem, a common path should be chosen in order to avoid various incompat problems"

an they're right - i've seen the results of installing to distinct paths - a lot of running around and manually editing jdbc driver paths whenever you try a clean checkout from the source repository...

that's what i meant - why jeopardize the entire development process because of personal preference...

an they're right - i've seen the results of installing to distinct paths - a lot of running around and manually editing jdbc driver paths whenever you try a clean checkout from the source repository...

I think they are talking about just WSAD(Eclipse) installations. I've seen it many times. It is easy to do. I would say that using different IDEs would solve this problem sooner or at least force you to think about not depending on IDEs (which we shouldn't).

At least it isn't as bad as VB. :) I've got some horror/funny (depends on how you look at it) stories about team VB development. .Net is a little better, but... .

IDE vs IDE is more like Hammer vs Hammer.Hammer vs ScrewDriver is more like Java vs .Net.

fully agree, futher i believe
 ide vs ide - car vs car
 lang vs lang - car vs boat
 methodology vs methodology - car vs house
 os vs os - car vs house

first case it's not so dangerous to take the wrong car, but in others cases, making the wrong choice seems to lead to unexpected results.

Otherwise, you end up with a Zoo where code is unreadable and bugs happen in one environment and not the other.

Do you want well tested code or not?
If bugs are poping up on developer/QA machines in Java project it is GREAT!
Usually means hardcoded path separators and such.
And yes, there are JVM specific issues, but:
- Java is supposed to be WORA;
- we (at least I ) do not want to dictate which JVM people should use, I want to give them working code.

and of course one Opearating System

Oddly, many places code on windows and deploy to Linux/Unix. Seems to work pretty well.

..this too depends upon your definition of failure. If by failure we mean 'not profitable', then the VAST majority of J2EE projects FAIL.

Why J2EE Projects Fail? In my view requirement gathering and functional specification is one of the reasons. On the other hand, team is playing more important role, but proper co-ordination and regular interaction among team members start from technology decision to architecture are very important to make a J2EE project success.

Because they are not using .Net :)

Would be iteresting to know once you are in this vicious circle of bad understood requirements, poor performance and strict technology dependencies how to argue a powerpoint sales manager of changing directions. Well it should be mentioned being just a developer.
The name "software industry" is really out of place because it is still a political artist contest.

Would be iteresting to know [...]how to argue a powerpoint sales manager of changing directions.[...] The name "software industry" is really out of place because it is still a political artist contest.

+1

The most common reason for project failure is definitely that project teams, after all these years, still use a waterfall process model. The way to go is to adopt one of the agile development processes and the failure rate will drop.

/Tommy
VisionProject
Issue tracking and project management made easy

Personally I'm working since a couple of years with Scrum and it works very good. Think it's because of the iteration cycles that increase the feedback from the clients, they are much more involved, the team knows exactly priorities and everything works better...

Personally I'm working since a couple of years with Scrum and it works very good. Think it's because of the iteration cycles that increase the feedback from the clients, they are much more involved, the team knows exactly priorities and everything works better...

+1

Our team had our own development process, full with requirements gathering, individual features to be developed, priorities, etc. When we came across Scrum, we realized we were doing 90% of their suggested practices, so we look at what we weren't doing and decided to adopt them.

Following Scrum's practices (with slight modifications) has made us more accurate at estimating time-to-customer and it has decreased the amount of time it takes QA to get ahold of something they can test. This keeps QA from being hammered all at once with a huge build where they are more likely to miss bugs.

The key for us has been keeping the customer involved throughout the development process and trying to keep builds small (4-6 week cycles). We force the customer to priorize functionality. Then development and QA estimate time to implement/test. Once estimates are complete, the customer has to approve them before development begins. This keeps the customer informed about how long the desired features will take and it forces them to sign off on the development.

Large features can be pushed off onto later builds if they consume too much effort. We had a priority 2 (1 being most important) request that was going to take weeks to implement. However, if we dropped it from the build, we could get priorities 3-12 in instead. It was up to the customer to choose, and they decided the other features, while independently less important, were collectively a higher priority. So they rearranged priorities and the 2 became a 12 and dropped from the build. The next build, it was a 1.

Another example, we had a request come in where they wanted us to make it easier to handle a situation that occurred in .1% of the orders we took, if that. We explained it would take us roughly 40 man hours to complete this task, forcing the build out by a week. They decided the cost was not worth the benefit, and scrapped the request all together.

That, my friends, is software development at its best. Analyzing ROI, having the customer prioritize features, short build cycles with quick testable deliverables, it has been a complete success.

I highly suggest analyzing Scrum to see if it is right for your project. It wont be for all, but I think a vast majority will benefit from its practices. I also think customizing it to your projects needs is necessary. Dont take it as "the way". We dont.

The most common reason for project failure is definitely that project teams, after all these years, still use a waterfall process model. The way to go is to adopt one of the agile development processes and the failure rate will drop.

Seriously, if you think the process alone solves the problems then you haven't been on that many projects or you've benefited from having a strong leader in place when you switched to a different process.

Picking the right process (or parts of a process) is definitely important but having a team that works well together, collaborates, and has a good leader that keeps the team focused and shielded from unnecessary disruptions is where the difference lies. And while processes can specify these sorts of things, unless you've built the team that can implement it, you won't get out of neutral.

A successful project also depends on picking an appropriate technology (note that there is probably not just one), setting realistic goals, and managing expectations outside of engineering.

Keep in mind that there were successful projects before Agile and there will be successful projects after Agile is no longer the process du jour.

I'm sure I've forgotten other things that are critical but those are the things that come to mind.

Seriously, if you think the process alone solves the problems then you haven't been on that many projects or you've benefited from having a strong leader in place when you switched to a different process.

Well, I have 8+ years of experience and have in that time been involved in quite a few projects but of course I still have a lot to learn. For me it has been a huge difference to have a lightweight, adaptive process instead of having a detailed analysis phase where the complete scope of a system is decided. I have never seen a customer that knows exactly what she wants from day one. So I really, really think that the most common reason for project failure is that a lot of teams still use a rigid waterfall process model where change is considered to be something evil and should be stopped at almost any cost. Prepare for change instead!

Picking the right process (or parts of a process) is definitely important but having a team that works well together, collaborates, and has a good leader that keeps the team focused and shielded from unnecessary disruptions is where the difference lies. And while processes can specify these sorts of things, unless you've built the team that can implement it, you won't get out of neutral.

I agree and what you describe above happens a lot easier with the use of Agile development processes.

A successful project also depends on picking an appropriate technology (note that there is probably not just one), setting realistic goals, and managing expectations outside of engineering.

Of course and agile processes does that much, much better than a waterfall process model.

Keep in mind that there were successful projects before Agile and there will be successful projects after Agile is no longer the process du jour.

Absolutely, and most of the practices of agile software development have been used for a long time even before Scrum, XP, DSDM, FDD, and so on, was “invented”...

Agile software development isn't for everyone but it fits most of the projects out there and it has solved a lot of problems we had in our projects.

/Tommy
VisionProject
Issue tracking and project management made easy

How would I do this ?

Or is that defeating some or other heigher purpose ?

I initiated a thread on this topic at one point. The gist of the response was, 'we get this request a lot, we're thinking about it, but we don't want other sites to rip us off'. I've resorted to using an app to capture the output from my audio card, but its not terribly convenient - I still have to wait for the tech talks to stream through my browser. Basically, I set up a tech talk to stream/be recorded just before going to bed.

I think the point is - How much J2EE is responsible for J2EE Projects failure

I think that this is a great presentation and problems discussed are not J2EE specific. Remote calls are expensive with any technology and should only be used when they absolutely needed. Too often remote call is seen as adding flexibility to the design even if it impossible to envision why would somebody want to call that method remotely. Abstraction layers are often added to abstract some things that do not need to be abstracted and soon a simple method grows with several wrappers build around it (to much needless complexity). Developers are often seeing architects as bunch of people wasting tons of real (and virtual as in Power Point presentations) paper and developer’s time. Communication is weak. I think that this is a great presentation, very properly identifying most common problems with many failed projects. (By failed I mean it could've been done much, much better).

In the past 12 years, I have seen more than dozens of failed projects, more than 50% of them are caused by so-call architect's stupid design. Hiring a hand-on architect is more important anything else if you want your project to be success.

Is there possible to have presentation slide available for download?

There are just too many theories, patterns and methodologies floating in J2EE world that simply divert attention away from the real goal of the project.

Well well, I think software projects fails out of various reasons, like weak requirements, bad staffing, wrong toolset, unknown production parameters and underestimation of tasks at hand.
However, I do not think that this is specific to J2EE, as this is an environment that has fairly straightforward explicit programming practices and problem breakdown structures. Actually, you can even work in a typical J2EE environment (without the usual "portal" bells and whistles) without using a debugger.

I am almost certain that really complicated GUI projects are even more volatile and will amass at least as much failures. Understading programs without debugging is almost impossible, coding requires multithreading more often than J2EE programming, interaction patterns are far more fine grained. And most of all, there is no "standard" like J2EE, Swing is bizarrely underspecified and incomplete.

Compared to the limited support and components we have for GUI programming in Java (and that includes the crude web gui attempts as well), J2EE tastes very sweet indeed.

Business complexity and well-defined requirements are
paramount - building a global supply chain system or
a domestic equity trading system. From a broader
perspective, IT has gotten a bad rap on not delivering
what is promised. J2EE is no easy beast to tame as my peers
will testify - EJB 3.0, JSF, XSLT, Struts, portlets, JVM, midlets, J2ME linkages, etc. Basically I see two unavoidable corporate impediments. A CIO only is as good has his/her CTO and the J2EE team at hand and whether the project manager(s), architect(s) can translate the business of making money into a robust technical system. Who cares whether a EVP of a business unit is certified or not. The second aspect which is the trickiest to deal with is the inherent corporate politics - budgeting, staffing, hiring, HR, use of employees versus consultants, outsourcing. Are there enough soft skills in the organization or are there one too many prima donnas in the IT department. To those
that think they have every answer in the company has probably written so much proprietary code that no one can unravel or delegate it for fear of being let go
or he/she should be bright enough to generate worthy
technology patents and attract real venture capital.

In my experience most important factor for any project(small and medium size) success is:

1. Business Knowledge of development team.
2. Communication with users
3. Iterative Development.
4. Finalizing UI upfront.

Techonology has to do little with any project success and failure.

Practicing of agile software development will help a lot to achieve this.

So please stop blaming technology.

In my experience most important factor for any project(small and medium size) success is:
1. Business Knowledge of development team.
2. Communication with users
3. Iterative Development.
4. Finalizing UI upfront.

0. People

Characterizing People as Non-Linear, First-Order Components in Software Development (A. Cockburn)

Joserra
Najaraba

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.

While most of us can agree that most of the reasons j2ee projects fail are not j2ee specific, I think there are probably some that might be.

I think that j2ee (pre 3.0) may have had a too steep learning curve. People venturing into j2ee territory may have used too many braincycles on understanding technology, so design process may have been depleted. There also seemed to be a lack of best practice guidelines for j2ee application design, petstore alledgedly contains a fair share of anti-patterns and apears to be too big to serve as an introduction.

I think what is needed is an incremental pet-store application that shows j2ee best practices bit by bit.

There seems to be an enourmous gap between. j2ee-"Hello World" (if such exists) and petstore. It apears to have been up to each developer to close this gap for himself, not everyone can manage this first time around and whatever projects people work on may suffer because of it.

Why mr johnson do not like the RUP??

Why mr johnson do not like the RUP??

...
she's RUP she's RUP
she's in my head
she's RUP she's RUP she's RUP
...
RUP lingered last in line for brains
...

Sorry, but everytime I hear RUP I think of that song.

?

Understanding the contract vehicle/funding source of your project plays a vital role in determining your strategy for preventing project failure. In fixed price engagements and/or fixed cap deliverable engagements the Client's respect (or lack thereof) of project schedule (task completion on data conversion for example) and previously approved deliverables are especially detrimental to fixed price projects.

Seems to me many of the people responding so far haven't understood what Rod was talking about all that well.
Time after time the comment is "if only XXX is used the project will succeed", where XXX is anything from someone's favourite editor to a favoured methodology.
In reality NO SINGLE thing makes a project (though as Rod states a single thing may break it).
Only when the right set of tools and methods for the problem at hand is chosen can a project bring optimal results and the exact set of tools and methods to choose differs from project to project.