88% uptime for J2EE apps

http://www.eweek.com/article2/0,4149,1388643,00.asp

I'm not sure what to do with this in the absence of comparisons to other platforms.  If design and code is bad fine, but if there are app server and virtual machine issues causing this, I, as a J2EE developer would like to know.'

Does anyone know numbers for other platforms

Name withheld out of cowardice
Wednesday, November 19, 2003

"In related news, Company X noted that automobile users only experience 75% uptime. No mention of the age, quality or condition of the automobiles were given."

This survey could mean anything. It could mean these companies have less than stellar developers. It could mean that their IT architecture blows. And it could mean that J2EE has issues.

Heck, I'm a .NET guy and love to poke fun at J2EE, but that study doesn't sound very scientific.

They said they would release the study on Thursday. I'd be interested in seeing if they cover the reasons for the failure, or just group them into the "J2EE failed" bucket.

Mark Hoffman
Wednesday, November 19, 2003

That is marketing article addressed to non-technical managers.

It could be 60%, 80%, 96% and any other number. Uptime is a question of hardware. Optimally designed software is only a benefit for better utilization of hardware resources.

Evgeny Gesin /Javadesk/
Wednesday, November 19, 2003

"Uptime is a question of hardware. "

That is only true of "uptime" means that the machine was functioning.

Uptime refers to users being able to do their jobs, customers being able to place orders, etc. And that almost always involves software. If the software craters it really doesn't matter that the hardware is purring smoothly, does it?

Not Me
Wednesday, November 19, 2003

This is a summarized version of a general - How was your J2EE today? poll.  I am always suspect of a poll that proves you need a company's service. 

"The survey,... pulled in responses from a self-selected group."
-  Bad Statistics.  People who get bad service are something like 8 times more likely to comment than people who get good service.  Self-selected groups always fall into this category.

" only 42 percent of the time, the application performs as planned when it's deployed.  Sixty percent of the time, it's not meeting user expectations"
- Expectations are a dangerous thing, they tend not to be managed well, because we all "know" something.  However, the users in the first project meeting were told it could do everything from full motion video to ending pollution all in sub-second response time.  That they never attended another meeting, where the topic of $12 trillion to develop meant some of these were eliminated, means they project did not meet expectations.

I could go on, but the simpliest solution for these things is a dose of reality and McConnell's "Rapid Application Development".

MSHack
Wednesday, November 19, 2003

There are many variables referenced in this study, so I don't see how a correlation can be made to the 'J2EE platform'.

Consider that most of the problem causes given have to do with staff as opposed to J2EE itself...

In order of frequency after application code bugs were: issues with configuration and tuning, architecture, database connections, design problems, memory leaks, capacity planning miscalculations, Java virtual machine issues, and then nine other categories of problems.

Scot Doyle
Thursday, November 20, 2003

  Recent Topics

  Fog Creek Home