|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 47
Messages: 47
Messages: 47
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Symposium Presentation: Rod Johnson - Why J2EE Projects Fail
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
|
|
|
Message #174389
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Symposium Presentation: Rod Johnson - Why J2EE Projects Fail
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!
|
|
|
Message #174420
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Symposium Presentation: Rod Johnson - Why J2EE Projects Fail
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$.
|
|
|
Message #174424
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Symposium Presentation: Rod Johnson - Why J2EE Projects Fail
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.
|
|
|
Message #174425
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Symposium Presentation: Rod Johnson - Why J2EE Projects Fail
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
|
|
|
Message #174427
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Symposium Presentation: Rod Johnson - Why J2EE Projects Fail
Just be patient... it takes some time to load ;)
|
|
|
Message #174431
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Actually, 70% of large scale internet projects fail...
..this too depends upon your definition of failure. If by failure we mean 'not profitable', then the VAST majority of J2EE projects FAIL.
|
|
|
Message #174432
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Symposium Presentation: Rod Johnson - Why J2EE Projects Fail
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 ;-).
|
|
|
Message #174434
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Why Software Projects Fail...
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
|
|
|
Message #174437
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Symposium Presentation: Rod Johnson - Why J2EE Projects Fail
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).
|
|
|
Message #174440
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Why Software Projects Fail...
>The way to go is to adopt one of the agile development
>processes and the failure rate will drop.
So what do you suggest?
|
|
|
Message #174448
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Scrum
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...
|
|
|
Message #174450
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Symposium Presentation: Rod Johnson - Why J2EE Projects Fail
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
|
|
|
Message #174452
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Symposium Presentation: Rod Johnson - Why J2EE Projects Fail
[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.
|
|
|
Message #174453
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Download for later viewing
How would I do this ?
Or is that defeating some or other heigher purpose ?
|
|
|
Message #174455
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Symposium Presentation: Rod Johnson - Why J2EE Projects Fail
I think the point is - How much J2EE is responsible for J2EE Projects failure
|
|
|
Message #174458
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Symposium Presentation: Rod Johnson - Why J2EE Projects Fail
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.
|
|
|
Message #174470
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Symposium Presentation: Rod Johnson - Why J2EE Projects Fail
[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 :)
|
|
|
Message #174488
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Why Software Projects Fail...
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.
|
|
|
Message #174491
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Download for later viewing
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.
|
|
|
Message #174497
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Great presentation
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).
|
|
|
Message #174500
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Symposium Presentation: Rod Johnson - Why J2EE Projects Fail
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.
|
|
|
Message #174502
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Great
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?
|
|
|
Message #174503
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Scrum
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.
|
|
|
Message #174504
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Symposium Presentation: Rod Johnson - Why J2EE Projects Fail
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.
|
|
|
Message #174505
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Symposium Presentation: Rod Johnson - Why J2EE Projects Fail
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.
|
|
|
Message #174542
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Symposium Presentation: Rod Johnson - Why J2EE Projects Fail
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.
|
|
|
Message #174545
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Why Software Projects Fail...
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
|
|
|
Message #174555
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Project Success/Failure
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.
|
|
|
Message #174575
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Symposium Presentation: Rod Johnson - Why J2EE Projects Fail
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.
|
|
|
Message #174590
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Symposium Presentation: Rod Johnson - Why J2EE Projects Fail
> - 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.
I don't agree in general. Most J2EE applications are written for a specific client with a specific environment. We should you neglect that fact?
For instance, should you neglect the fact that Orcale has a different SQL dialect as, let's say, Postgresql? Ofcourse we do need an abstract layer to interact with a database so our 'upper tiers' are free of platform specific code.
|
|
|
Message #174592
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Its not just J2EE...
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.
|
|
|
Message #174596
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Symposium Presentation: Rod Johnson - Why J2EE Projects Fail
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.
|
|
|
Message #174638
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Contract Vehicle: Fixed Price versus Time and Materials
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.
|
|
|
Message #174702
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Symposium Presentation: Rod Johnson - Why J2EE Projects Fail
and of course one Opearating System Oddly, many places code on windows and deploy to Linux/Unix. Seems to work pretty well.
|
|
|
Message #174703
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
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.
|
|
|
Message #174770
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
environment dictate
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
|
|
|
Message #174797
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
environment dictate
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.
|
|
|
Message #175166
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
environment dictate
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...
|
|
|
Message #175177
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
environment dictate
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... .
|
|
|
Message #175393
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Symposium Presentation: Rod Johnson - Why 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.
|
|
|
Message #175538
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Symposium Presentation: Rod Johnson - Why J2EE Projects Fail
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.
|
|
|
Message #180090
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
environment dictate
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.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Download the entire book of Jakarta-Struts Live and learn about Struts MVC, Tiles, the Validator, DynaActionForms, plug-ins, internationalization, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
