Early in your project, typically part of your environment workflow efforts if you are following either the Rational Unified Process (RUP) or the Enterprise Unified Process (EUP), you need to define your project team's technical environment. This encompasses selecting and then installing the appropriate standards, guidelines, and development tools that your project team will use.

To be successful at this effort you must consider the following:

1. Recognize that tools, standards, and guidelines are always getting better. Any tool you choose today will likely be superceded tomorrow by one of its competitors. Does that mean you should switch tools? Likely not, because the cost of purchasing it, installing it, and retraining the whole team on it will likely outweigh the benefits of its new features. Besides, your tool vendor will soon release a new version of its own to keep up with the competition, and the last thing that you want to do is yo-yo back and forth between development environments: Do that and you'll never get around to your real work -- the development of EJB software. Changing tools, particularly in the middle of a project, can be a risky and expensive process. If you find that a tool does not live up to your expectations, then you should consider dropping it or upgrading if a new version exists. But if the tool works well, then stick with it. The same thing can be said of standards and guidelines.
2. Set up your project environment as early in the project as possible. Your project environment lays the foundation for how your development team will work together, so you need to lay the foundation as early as you can. Teams that leave tool selection to the last minute find that they do not have enough time to train everyone in their effective use. Leaving the choice of standards and guidelines until late in the project results in inconsistent work, strife within the team, failed reviews, and sometimes even significant rework.
3. Product reviews are useful, but not the final say. When you do a quick search online you can find a wide variety of independent product reviews -- particularly in magazines such as JavaPro, Java Report, and Software Development (see Resources) -- that give you a pretty good idea what each tool can do. Reviews help you to narrow your scope, but you'll still need to evaluate the tools within your own environment to make the final selection. You should also consider hiring a consultant to help you define a project environment and to ensure that you make the most appropriate choices for your situation. Furthermore, newsgroups for the specific tools, or portal sites such as The Server Side (see Resources) provide very good insight into what actually works.
4. Your project environment must reflect your methodology/process. When your project environment and software process are inconsistent, your team will quickly discover that it needs to expend significant effort to stay on schedule (due to the need to work around challenges created by its insufficient project environment). For example, if you're taking an iterative and incremental approach to development, you need testing tools that strongly support regression testing. Otherwise you'll be handcrafting your own regression test suites. Also, if you've chosen to take a use case-driven approach, then you obviously need tools that support development of use cases.
5. Choose your project environment based on requirements. If you don't know what you're shopping for then why are you shopping? For example, before you can choose your testing tool(s), you need to first identify the types of testing you intend to perform.
6. Don't evaluate every single option in each category. There are hundreds of development tools available to Java developers, but you will only use a handful of them on your project. Narrow your scope to a few candidates, obtain review copies, put them through their paces, choose your environment, and move forward. Remember the KISS principle: Keep It Simple, Stupid!
7. Adopt a tool only if you will benefit from it. Purchasing a tool that costs $3,000 per developer seat is a good deal if everyone is using it to its full potential. However, it's an incredibly bad deal if your developers are only using a small portion of its capabilities that could have been obtained from a simpler and less expensive tool. Also, remember that you can find a wide range of free tools online with a bit of searching.
8. Expect to train. You can't put a tool, or a standards document, or a software process on someone's desk and expect them to be proficient with it that very day. For more on this, see last week's tip on EJB training. (Also note that next week's tip will address further training issues).
9. Adopt existing standards, guidelines, and tools. Although it is often tempting to try to write your own development guidelines, or build your own tools, or integrate several tools on your own, you should only do so if you can do it with very little effort. Otherwise, you are better off adopting a pretty good, although not perfect, project environment and getting on with your real job of developing software.

Note: This tip was excerpted from the forthcoming Mastering Enterprise JavaBeans, Second Edition to be published in autumn 2001.

Resources

• This is the third tip in a series dedicated to Enterprise JavaBeans. Read the first two for background:
  • Choosing an EJB application server
  • EJB training: Start your project off right
  
  
  
• Product reviews are a good place to start the tool-selection process. I find the following sites offer good reviews:
  • JavaPro
  • Java Report
  • Software Development
  
  
  
• The Server Side is a middleware portal where you'll find a wide range of peer reviews.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• Resources
• About the author
• Comments