Advanced Java 2 Development for Enterprise Applications (Sun Microsystems Press Java Series)

Read an Excerpt

Chapter 1: The Java Project Lifecycle

Introduction

• What are the issues that come up in a Java project?
• How are these issues different from other kinds of projects?
• What steps can you take to minimize risk in a Java project?
• How should you fine-tune your development methodology?
• What design guidelines should you use? coding guidelines? testing techniques? measurement techniques?

Risk Management

• New technology abounds, seemingly in every area of the project.
• Rapid delivery is required-people can't wait nowadays.
• Many disparate elements are required, often from multiple vendors.

It seems like every six months there is an entire new class of products and APIs, designed to fill spaces unaddressed by those from before. Many server vendors also now make major enhancements to their core products more than once makes it hard to build a system, because there is the risk that the prod liable or have unanticipated behavior, or advertised features are not quite ready.

Sometimes it is wise to forego a new class of products or a new API until it has matured. The problem is, you never get to that state anymore. If something is so mature that it is no longer evolving, it is dead. The problem is not that products evolve; it is the rate of evolution that has sped up, as a result of the tremendous growth of the Internet and the spread of computers to mainstream and even home use.

The Java core API is a good example of an evolving technology. The hunger for enhancements is so great that people are usually willing to put up with bugs in to use the new features. Take the Swing API. When Swing was in beta 0.5, we already had clients using it for mission-critical applications. They could not be dissuaded. The reason was that, even though it was buggy then, it would become stable by the time it was officially released, and they wanted to base their development on a standard. Swing was also so much nicer than its predecessor, the AWT, that staying with the AWT was not even an option. One could say that this is a special case, because the AWT was flawed, but in fact it is not a special case, because in every corner of Internet technology you see this - a constant outcropping of things so new and so different that they cannot be dismissed. In the case of the aforementioned clients using Swing, it ended up being a good decision, because those applications are completed now and are very stable.

Not all of these new inventions have staying power, however. When Internet "push" technology first appeared, it was touted as the new wave that would drive our desktops from now on. As it turned out, this technology's strength is in the deployment of applications, as opposed to dynamic desktops. In only one year, the entire perception of how this technology should be used made a complete turn. It is a major challenge for a manager to sort the promising technologies from the doubtful ones, and move cautiously but at the same time without fear of using something new - because everything is new.

The viability and professionalism of the provider of a technology must also be considered when making a selection. A great many Java product companies are startups, or small organizations recently acquired by larger ones. Of course, all companies start small; in the mid-80s Oracle was a fledgling company and an underdog, battling against mainframe Codasyl and IMS databases, so smallness itself should not be a handicap. It is a red flag, however. In one project, an object-oriented "blend" product was selected to provide an object-oriented layer for a relational database. Many vendors were evaluated, and since the Java binding of the Object Data Management Group (ODMG) standard for object-oriented databases was fairly new, not all vendors had incorporated it into their products. As a result, there was quite a bit of disparity between the models used by the different vendors. The vendor that was finally selected was persuaded to agree to accelerate the schedule for certain feature enhancements of interest to the project, at the expense of others. Since they were a small vendor, and this was a large customer, convincing them was easy. They made the changes, but when the product started to be used, other unanticipated limitations were discovered. Luckily, this was during a prototype stage for the project, because the limitations necessitated reconsideration of the project's core architecture.

The Constant change of technology is a major problem for staff training. It is virtually impossible to staff a project with people who have experience in all the thingsyou want to use. I recall seeing an ad in a newspaper in February 1996, for a programmer with "2+ years of Java development experience." Apparently the human resources person who wrote the ad was not aware that at the time there were perhaps 20 people in the world who fit that description, and they were very busy.

The cost of obtaining specialized talent can also be a factor that reduces flexibility and increases risk. One project I consulted on originally had decided that the best technology in which to implement their application was Lotus Notes. However Java was selected because it was calculated that while Lotus Notes developers could be found, the cost of obtaining them in the required numbers would double project costs compared to using C++ programmers and training them in Java.

The incentive to tolerating these risk factors is that these new technologies promise lower-cost development, much wider deployment and end-user productivity and functionality, and greater adaptability. To get control of the risks so that these gains can be realized, a strategy is needed with new emphasis on rapid delivery in a core-capability-driven manner. To this end, I propose three rules to comprise this strategy. Surely you have heard these and other rules before, but I am putting these three at the top of the list.

Rules for Success

The second rule is focus on the primary mission of the application, and make that work really well. Concentrate on what the application has to do most of the time. Tune the System for that. A system that does everything equally well is either overfunded or in fact does everything in a mediocre manner. If the primary mission is processing orders, design the system for that. If the primary mission is checking patient records, design the system for that. In large systems that are built in stages, sometimes the wrong piece is built first and then drives the rest of the design. For example, if the system must interface to an external system, a data loading mechanism might be built early on, and the system's primary features added later. Unfortunately, when this is done, there is a risk that the system will be tuned for the data loading process, which is not the primary purpose of the system. The result is a system that may load data well, but has poor response time for calling up data-the primary mission and success criterion of the system.

The third rule is if using new technologies, build a prototype, and deploy it early. You cannot avoid using new technologies today, and things are changing all the time. The best way to deal with this unstable situation is to move quickly, to avoid obsolescence, but prudently, to manage the risk of using new features. Don't commit to an architecture without building a prototype that tests the core mission-critical functionality using the new technologies. That is the only way that technology limitations will be exposed so that a successful full-scale architecture can then be designed. Further, it takes someone with a great deal of experience with load these technologies to judge where the risks might be, and what features prototype development should focus on. You should also make a point to deploy your prototype in the actual target environment, at an early phase, long before the final deployment date. Deployment is one of the most treacherous aspects of building these systems, because only then do you discover for real the interaction of security systems, application servers, and the real databases they will run with, as well as bugs and weaknesses that suddenly crop up in a great many of these products. What should take days can often take weeks, and if such delays are to occur, it is best to leave plenty of time for the inevitable workarounds....

Read More