This article discusses aspects of a project undertaken by our Developer Relations Technical Consulting team. Using eXtreme Programming (XP), we built a Web application with IBM development tools and technologies for a fictitious company called Go-ForIt.com. We discuss the genesis of the Go-ForIt project, including why the project was undertaken, and project goals and objectives. We also provide a high-level overview of the application built in this ongoing project.

A major goal of the Go-ForIt project was documenting our experiences and what we learned. This article is the first in a series in which we'll share those experiences and the knowledge gained. Future articles will give detailed explanations of the components developed for the Web application, discussions of the architecture and design decisions, and the lessons we learned during development.

How we came to be called DragonSlayers

The Developer Relations Technical Consulting team provides architecture, integration, and consulting support to IBM business partners using IBM software tools and technologies. Our mission is encapsulated into something we call the Four E's: Excite, Evangelize, Educate, and Enable. We excite developers about IBM offerings through presentations and speaking engagements. We evangelize the IBM vision of open, standards-based development. We provide formal education on IBM software. And we enable developers to use IBM tools and technologies through phone, Web-based, and on-site consulting.

When the team or one of its members solves an extremely tough problem, or has especially delighted a customer (by giving training and enablement support that saves time and effort in their development), we, as a team, make a special point to congratulate and celebrate that work. We began referring to such outstanding work as slaying a dragon, and it didn't take long until we nicknamed ourselves "the DragonSlayers."

All of us DragonSlayers are programmers, and our years of experience in software development is a significant factor in our effectiveness. To make our business partners successful, we cannot tell them only about our products and why they should use them, we must also tell them how to use them, in gory, technical detail. Only a programmer can effectively relate the how to another programmer.

Another critical factor for us is learning. If we're going to teach and enable our business partners, we have to be the experts. It's an obvious but true statement that software technology is advancing at a rapid pace, probably more rapidly than at any other time. DragonSlayers are constantly challenged to stay abreast of and maintain their expertise in the tools, technologies, and standards coming out of the labs. This means a lot more than reading manuals, for we all know that reading a manual does not make anyone an expert. You have to actually use the tools and technologies. We spend considerable time and effort getting our hands dirty to understand the nuances and intricacies of each new product or version.

Back to top

Risky business

As more companies adopted the IBM Framework for e-business and its attendant tools and technologies, and as our team grew to meet the support requirements of those companies, we faced risks to our ability to continue providing the superior consulting we knew we must provide.

The first risk was with getting skills and knowledge fast enough to stay ahead of our customers. The time and effort we spent getting hands-on experience could not compare with the experience our customers were gaining by using the products every day. Our customers were developing large, complex systems, and pushing the capabilities of the IBM products they used to build those systems. Our primary mission is to lead and guide our customers, but we risked letting that role slip away as our customers became more adept with the tools and technologies than we were.

The next risk concerned the overall software development experience of our staff. We know that, in addition to technical skills and abilities, software development also entails processes and methodologies. It involves analysis and design, teamwork and cooperation, and, probably most importantly, pride of ownership in a functioning system that delivers a technological solution to a pressing business problem. The longer we stayed consultants, the farther into the past our "real" software development experience faded.

Which led us to the final risk we faced -- the response of our team members to the first two risks described. It became apparent that some, most, or even all of our team would eventually leave the team and join a development organization to gain the skills and experience they felt they needed. Considerable effort went into recruiting and training our team, and we didn't want to lose any of our valuable people.

Back to top

Solution: Go-ForIt.com

One evening, while discussing these risks at a local pub, we came up with a solution to our problems. We believed that undertaking a "real" development project would help us address and minimize the risks we faced. We agreed that our project:

• Must be of sufficient size and scope to involve all members of the Technical Consulting team
• Must not be an application that will ever be placed into production
• Must, however, be realistic and believable as an actual solution to an actual problem
• Must lend itself to using most of the IBM Framework for e-business products and technologies in its implementation, and be representative of our customers' problems and solutions
• Must be open-ended, and subject to constant improvement and enhancement

There was some debate on the second criterion, but in the end, we knew that our mission was supporting IBM business partners, and we didn't want to create a conflict between users of our application and our actual customers.

The project we had in mind was the development of a Web site for the fictitious company Go-ForIt.com. Go-ForIt.com was a personal errand service. A customer would register at the site and post errands they needed done; for example, picking up laundry, walking the dog, standing in line at the license branch, and so on. Independent contractors, known as Personal Assistants (PAs) would also register at the site and bid on posted errands. Go-ForIt would match up the winning bid with the customer in need and collect a percentage of the fee paid for completion of the errand.

We know that, as a business model, Go-ForIt.com would rank up there with the zaniest of the dot coms that went bust in the past year, but our emphasis was on the technical side of things, and we believed this application met our criteria.

Our main goal was to gain realistic software experience, but we realized that Go-ForIt.com could help us achieve two other important goals of the team. First, we could derive most or all of our curriculum materials from the project, and, second, we could extract frequently asked questions, hints and tips, technical papers, and other technical content to share with the software development community.

It's Willy's fault

To complete our idea, we developed a set of principles to convey the tone and philosophy of our project, as follows:

1. Everything concerning this project is open to sincere, reasoned, thoughtful challenge, even these principles. Every team member has an obligation to question decisions they don't understand or thinks to be wrong.
   
   
2. We will not lose sight of our primary mission to support our customers. That mission takes precedence over everything else, including this project. After all, we are embarking on this project to gain skills and experience that will enable us to better support our customers.
   
   
3. We will not, however, treat this project as an extracurricular or optional activity. We will treat the assignments, schedules, deadlines, and so forth as seriously as if they were for a real project intended for actual deployment.
   
   
4. Everything about this project will be established and managed as a real project, including configuration management, coding standards, schedules, deadlines, documentation, integration testing, acceptance testing, emergency bug fixes, performance testing and tuning, and so on, always bearing Principle #2 in mind.
   
   
5. We will use eXtreme Programming (XP) as the development process. XP is a disciplined approach to software development based on the requirement to accept change as inevitable and to plan accordingly. We chose XP not because it's new and neat, but because it addresses the challenges we will face in this project. It is designed for vague and rapidly changing requirements, advocates short development cycles to maximize learning, and requires constant testing and refactoring of code to ensure its correctness. Our customers are evaluating XP; some might already be using it. We should have experience with this important innovation in software development to intelligently speak about it with our customers.
   
   
6. This project will not be run by committee or consensus. One person on the team will take the role of project manager, and make all project management decisions accordingly. One team member will take the role of project architect, and make all technical decisions. One team member will take the role of customer, and make all business decisions. One team will take the role of strategist, and make all decisions about what IBM products and technologies to include in the project.

   This principle is not contrary to Principle #1. Everything is open to challenge, questioning, and debate. But at some point a decision must be made to move forward. Committees are notorious for delaying and deferring decisions through interminable discussion. We don't have time for that. We do, however, envision rotating the roles among the members of the team over time, so all team members can gain experience in the different aspects of software development.

7. No team member will become a specialist in any one part of the project or any one product or technology used by the project. No team member can refuse to work on any part of the project, or with any product or technology used by the project, citing lack of experience. There will be no people assigned only to "thinking." Everybody slings code. There are no HTML specialists, Java specialists, JSP specialists, etc. We are striving for the broadest possible experience for all team members. We have collective ownership of the project, but each team member should also feel individual ownership of the entire project.
   
   
8. Whenever anything goes wrong, it's Willy's fault. This principle is part of the XP philosophy (adapted for local conditions). When problems occur, as they inevitably will, the natural reaction is to point fingers and assign blame. But that isn't very productive. We need to fix the problem, and whose fault it is doesn't really matter. So, whenever something goes wrong, we'll just blame Willy and quickly get on with fixing the problem.
   
   

Having worked all this out between ourselves, we formed our idea into a proposal and presented it to management, who loved the idea and quickly approved it. We then published the proposal to the entire team and held a meeting to answer all questions and address every concern. Next, we held training sessions on XP for for everyone involved, and commenced work on the project in January 2001.

Back to top

The Go-ForIt.com application

This section describes the Go-ForIt.com application, but still at a fairly high level. Future articles will delve into the details of the project development.

To start building the Go-ForIt application, and to be as true to the XP model as possible, we designated four team members as customers. They came up with a set of User Stories. User Stories are requirements told from a customer perspective and contain little or no implementation details. They are the customer's vision of how the system will be used. To keep things in simple manageable chunks and to avoid individual stories that were too long and complicated (some members of our customer team are notorious for their ability to wax poetic with little prompting on a variety of subjects), we required that each story be written on a 3 x 5 index card. Once the stories were defined, we began breaking each one down into a set of tasks and implementing the tasks. (You can see the entire list of stories and their current implementation status.)

Design philosophy

We approached the implementation of the User Stories with a blank page. We did however, have a set of general design principles we followed. These were guided by the User-To-Business pattern that is part of the IBM Patterns for e-business, a group of reusable assets that can help speed the development of e-business applications.

The principles we follow are:

• We use the Java programming language (someone on the team suggested using Perl and had to be escorted from the room under heavy security).
  
  
• The user interface (UI) is Web-based.
  
  
• Static portions of the UI are implemented with HTML.
  
  
• Dynamic portions of the UI are implemented as JSP pages.
  
  
• Persistent data (for example, user information, errand request information) is represented as Container Managed Persistence entity beans.
  
  
• Relationships between entity beans (for example, to indicate that an errand request was made by a particular customer) are handled using associations.
  
  
• All user actions are handled by servlets that call the appropriate methods on the corresponding session beans and then call the appropriate JSP pages to return the results of the action to the user.
  
  
• The Servlet interface to the session beans is simplified by developing a command bean, a simple JavaBeans component with setXXX() methods to provide user supplied data, an execute() method with no parameters to perfom the tasks, and getXXX() methods to supply the results (if any). The command beans throw exceptions to indicate error conditions.
  
  
• Tasks that affect the persistent data (for example, add a user, update a user's information) are represented by methods on EJB session beans.
  
  
• Simple user input verification (for example, verifying that a phone number was in the correct format, or verifying that all required input was present) is done using JavaScript on the client side.
  
  
• The application is deployable on any hardware platform that supports WebSphere Application Server.
  
  

Development tools

We are using the following tools to develop Go-ForIt:

• WebSphere Studio 3.5 Advanced Edition to develop HTML pages, JavaScript and JSPs.
• VisualAge for Java 3.5 Enterprise to develop all server-side code: EJBs, servlets and their associated helper classes. Associations between entity EJBs were done using the Persistence Builder Tools in VisualAge for Java.
• VisualAge for Java 3.5 Team Server to manage a single common repository used by everyone on the development team. For more information on using VisualAge for Java in an XP environment, see Resources.

Testing

One of the cornerstones of XP is that each project should have a comprehensive set of automated tests that test everything that could possibly go wrong (with the possible exception of acts of nature). When we find bugs, we write a test case to expose the bug and add it to the suite prior to fixing it. For more information on testing in XP, see eXtreme Programming: Deceptively simple innovation.

For our EJB components, command beans, and all other associated helper classes we use the JUnit testing framework (see Resources) to write the appropriate test cases.

Back to top

Conclusion

The Go-ForIt.com project was begun to accomplish our objectives of skill maintenance and technical information sharing. To maintain and increase the depth of technical skill of the consulting team, we're focusing the Go-ForIt project toward relevant areas (areas where our business partners are moving). With these relevant skills, we are able to achieve half of our organization's mission of educating and enabling our clients. However, we are mindful of the other half of our Four E's -- exciting and evangelizing to our clients. So, the Go-ForIt project reflects new technology as IBM introduces it and proposes it to our business partners. Go-ForIt tests the validity of technology and enables our consultants to speak credibly about it.

We are mining the Go-ForIt project for technical information to share: "how to" articles, sample code, relevant course topics, answers to frequently asked questions, and fodder for Mentored Workshops. Toward these ends, Go-ForIt has, up until now, been moderately successful. Through the perseverance of the team of consultants, however, Go-ForIt has gotten greater visibility and in the second revision is now featured here, where the lessons learned can be shared with and used by IBM business partners and individual developers.

Over the next weeks and months we'll document our experiences with Go-ForIt and share them with you. We'll talk about how we developed the various components, the design decisons we made, and the pitfalls and successes we encountered along the way. So sit back and enjoy the ride. We have learned, and are continuing to learn, a great deal from this adventure in codeslinging and we look forward to hearing from the developer community about what we did wrong, what we did right, and your own experiences in the e-business application development trenches or with XP.

Back to top

Stay tuned...

Watch for our next installment of the Go-ForIt chronicles. To see the other articles in our tale of dragonslaying, go to our overview.

Resources

• Participate in the discussion forum.
  
  
• Read the second article in the Go-ForIt series to learn why the DragonSlayers chose eXtreme programming to battle their way through the perils of developing their Web application.
  
  
• Explore IBM Patterns for e-business, prebuilt designs for creating and implementing large integrated systems.
  
  
• Visit the JUnit site for information about the JUnit open source regression testing framework that enables unit testing in Java.
  
  
• Learn about eXtreme programming in IBM VisualAge for Java in this article from IBM DeveloperToolbox.
  
  
• Review the User stories (customer requirements) for the Go-ForIt application.
  
  

About the authors

David Carew is an e-business Architect for IBM Developer Relations Technical Consulting in Austin, Texas, providing education, enablement, and consulting to IBM business partners. He joined IBM in 1988 and has held a variety of positions in development, from writing the code to control industrial robots to writing device drivers for AIX Wide Area Network devices. Somewhere along the way he learned Java, picked up an MBA from the University of Texas at Austin, and started consulting for Developer Relations. David is a Sun Certified Java Programmer, Certified Java Developer, and Certified Architect for Java Technology. You can reach him at carew@us.ibm.com.

Willy Farrell is the lead e-business Architect for IBM Developer Relations Technical Consulting in Austin, Texas, providing education, enablement, and consulting to IBM business partners. He has been programming computers for a living since 1980, began using Java in 1996, and joined IBM in 1998. Willy holds the following technical certifications, among others: Java Programmer, VisualAge for Java Solution Developer, MQSeries Solutions Expert, WebSphere Application Server Solution Developer, XML Developer, and IBM e-business Solution Technologist. You can reach Willy at (willyf@us.ibm.com).

Fred Gutierrez has the awesome privilege of providing overall direction to a team of consultants that venture forth and slay the dragons that haunt the e-business applications of IBM's business partners. He joined IBM in 1987 while attending Georgia State University. The team he worked on developed online education that was prepackaged with AS/400 systems (iSeries, for those who aren't as old as Fred). After graduating from GSU with a degree in accountancy, IBM sent Fred to Boca Raton to develop courses and redbooks on OS/2 application development. In 1994 good fortune smiled upon him and he was transferred to the live music capital of the world (Austin, Texas) to continue the same work. Fred joined the e-business Architecture and Integration team in 1997 as a consultant and continues to dabble in technology just enough to be able to have short conversations with the members of his team. Get this -- prior to joining IBM, Fred was a Highway Patrolman with the Texas Department of Public Safety. Send him a note at (fredgz@us.ibm.com).

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• How we came to be called DragonSlayers
• Risky business
• Solution: Go-ForIt.com
• The Go-ForIt.com application
• Conclusion
• Stay tuned...
• Resources
• About the authors
• Comments

Next steps from IBM

WebSphere Application Server can take you to the next step in the evolution of Web Development that lends itself to the creation of rich Web 2.0 user interfaces.

---

• Try: Download a free trial version of WebSphere Application Server Community Edition, a pre-integrated, lightweight Java 5 application server built on Apache Tomcat and other best-of-breed open source software such as OpenEJB, Apache Axis, and Apache Derby..
• Article: This article introduces you to the web development with WebSphere Application Server Feature Pack for Web 2.0. Its a good look at solutions for creating Ajax-based web apps and mashups.
• Tutorial: This tutorial takes you through the PHP and Java steps to master Facebook application Web development with the no-charge WebSphere Application Server Community Edition Web server.
• Demo: This demo showcases the WebSphere Application Server Community Edition administrative console feature set and walks you through deployment of a Web application.
• Buy: WebSphere Application Server - Express

My developerWorks community