The Artima Developer Community
Articles | News | Weblogs | Books | Forums
Artima Forums | Articles | Weblogs | Java Answers | News
Sponsored Link •

News & Ideas Forum (Closed for new topic posts)
Java and .Net Both a Disaster

8 replies on 1 page. Most recent reply: Dec 4, 2002 7:56 PM by Mike Spille

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 8 replies on 1 page
Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Java and .Net Both a Disaster Posted: Nov 25, 2002 4:03 AM
Reply to this message Reply
Advertisement
ZDNet Australia has published a short article by Angus Kidman that points to research showing 70 percent of initial Java implementations have failed, suggests that the failure rate for .Net will be similar, and recommends outsourcing development.

http://www.zdnet.com.au/newstech/enterprise/story/0,2000025001,20269968,00.htm

Here's an excerpt:

"An inordinately large number of large-scale Java projects have been failures," said Mark Driver, Gartner research director for Internet and ebusiness technologies.

However, Microsoft shouldn't draw any comfort from those figures as it seeks to promote its .NET technology strategy either. In all likelihood, the failure rate for early implementations of .NET systems will be similar, Driver said.

"The only practical way to mitigate the risk [of a failed implementation] is to outsource development."

Do you believe the 70% failure rate number? Why do you think so many projects fail? And is outsourcing a reasonable way to deal with failure, or will 70% of your outsourced projects fail too?


Berco Beute

Posts: 72
Nickname: berco
Registered: Jan, 2002

Re: Java and .Net Both a Disaster Posted: Nov 25, 2002 6:53 AM
Reply to this message Reply
My first reaction would be: "when is something regarded a failure?". This article doesn't hold much information if that has not been made more explicit.

Ryan Shriver

Posts: 9
Nickname: rshriver
Registered: Oct, 2002

Re: Java and .Net Both a Disaster Posted: Nov 25, 2002 11:48 AM
Reply to this message Reply
I have been on a few projects that "failed" (very vague term). Not a single one of them was due to the underlying technology failure but rather the lack of understanding in how to run a project.

I'd be interested to see if Gardner went back to those 70% of failures and actually found out what the root cause (or likely causes) were. My guess is that managers / major stakeholders in each of these projects wouldn't divulge the real reason(s) the projects failed, because it would make them look bad.

It's very easy for a stakeholder in a large, complex project to say "it was the technology that failed", when in reality is wasn't. They're covering their ass by deflecting blame. Maybe they tried to implement a big project using the cheapest resources they could find (i.e. no budget for architects, just get some coders in the room) and somehow it's the technology that failed. The reality is bad project management, lack of vision, etc. all contributed to the project failing. But it's easy to pin the blame on the technology because admitting it was something else would mean somehow the stakeholders failed. And we all know that stakeholders never "fail".

Read "Mythical Man Month" or "Peopleware". All this "so and so technology failed" business in most cases is pure BS. Yet Gartner continues to make a killing peddling their "insight" to managers and directors worldwide. After reading this, I'd be interested to know how many new J2EE projects failure gets pinned on the technology. After all, Gartner said so.

-ryan

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: Java and .Net Both a Disaster Posted: Nov 25, 2002 2:29 PM
Reply to this message Reply
I thought the failure rate for software projects in general was very high, particularly big ones.

I saw a big Java project fail recently at a big company. The original idea of the project in my opinion was a bit silly: take disparate information throughout the whole corporation and put it all in the same database and provide one app for everybody to access it with. It was interesting to me because it was clear to me that the technology had be misused and very badly implemented, but everyone insisted on blaming Java. The funny thing was, they had a very pretty and slick UI, but the client-server aspect was just done very stupidly; as if someone tried it out on about two or three machines connected together and said "it works!" It required downloading a ton of client code every time you used it and did other silly things like "Select * from table" on the database, and filtering locally. All these things work great with a small set of machines on a fast network, but of course, when a few thousand people connected at the same time, the thing came to a veritable standstill. This really has nothing at all to do with Java, but from the very first time I heard about this thing, people told me it was slow, "because of Java."

As far at that outsourcing argument goes, the guy who wrote the article probably provides outsourcing. I think big companies are doing too much outsourcing, to their own detrement; a self-imposed brain drain. This is good for the providers of the outsourcing, of course.

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Java and .Net Both a Disaster Posted: Nov 25, 2002 9:21 PM
Reply to this message Reply
It's been my experience too that failed projects have been the fault of the way a project was managed, or not managed. I've gotten the message time and time again that the most important ingredient for a successful software project is the talent and skill of the developers and especially, management.

Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Re: Java and .Net Both a Disaster Posted: Nov 25, 2002 10:12 PM
Reply to this message Reply
Note that the article said "large-scale Java projects." To me, when people think of their projects as being "large-scale," that's a synonym of failure already. I'm surprised that only 70% of large-scale projects fail... Also, how is failure judged? For me, if I learn something in the process, that's not failure at all.

I think a big problem is that many project managers fail to clearly set forth a project's success criteria. Too vague expectations always lead to failure, regardless of how talented the developers are. Setting short-term, daily, exceptations, on the other hand, makes success a habit. Suppose the goal is to accomplish X by the end of the day. The end of the day comes, and X still doesn't work. Well, then we can learn why it didn't work, what errors we made during the day. Next day we can take that learning into account, and do something different. It's almost impossible to fail that way...

Michael Donaldson

Posts: 1
Nickname: mdonalds
Registered: Nov, 2002

Re: Java and .Net Both a Disaster Posted: Nov 28, 2002 4:49 PM
Reply to this message Reply
Supposedly 80% of statictics are made up.

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: Java and .Net Both a Disaster Posted: Nov 30, 2002 10:57 PM
Reply to this message Reply
Yeah, and the other 30% are inaccurate.

Mike Spille

Posts: 25
Nickname: mspille
Registered: Nov, 2002

Re: Java and .Net Both a Disaster Posted: Dec 4, 2002 7:56 PM
Reply to this message Reply
In my experience, many projects fail because of inadequate or non-existent feedback loops. Some examples:

- Developers coding components in isolation, with the "big integration" at the end to pull everything together.

- End-users only see the system regularly in demos. In a one year effort they get to directly play with it only at the six month mark and the one year mark.

- Junior developers are given work tasks with no oversight from a senior person, their end product is not checked.

- "QA means your code compiles".

- The whole team is developing on a new OS/language/platform they've never used before, without testing the waters first on smaller, less risky projects.

- Requirements are locked down on January 1. Code delivery is on December 31st.

- No "view from 10,000 feet" of what the system's for, and what it's supposed to do, only endless minutiae.

- No "view from 10,000 feet" of the architecture, just code-as-you-go (some may call his approach XP :-)

- Reliance on beta (or alpha!) technology from a third party as a core piece of your architecture.

- No planned release cycle - keep coding 'till everything's done!

- Lack of basic tools. Source code control. Isolated QA environment. Reference databases. Automated tests.

Etc. etc. The real problem with nearly all of the above is work being done in a vacuum without feedback from other people.

Successful projects work when everything is visible, when there are regular iterations, when all the important stuff is trackable, when the user regularly hits the real system, when requirements are regularly re-evaluated vs. the reality of the growing system. When you work out production release procedures in the 2nd or third iteration, not in the end.

In short - multiple people interacting regularly (regularly is important) injects a healthy dose of reality into the process. When feedback is lacking, everything starts to drift off of true. The difference is like the difference between hiking to approximate way-points via landmakrs every 2 klicks, getting a read how far off you are and correcting - and trying to sail by feel from New York to London over the Atlantic.

As an aside: projects with little feedback are fabulous breeding grounds for lazy developers, shifty project manangers, and end-users with unknown agendas.

-Mike

Flat View: This topic has 8 replies on 1 page
Topic: Flexibility and Complexity Previous Topic   Next Topic Topic: Design Principles and Code Ownership
Sponsored Links


Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use