ou're building an e-commerce Web site for a high-profile client using the latest application server. The server and its technology are brand new to the entire computing world, but as your company's senior developer, you're expected to instantly be an expert on them. For one brief moment you wish you'd specialized in ancient Egyptian civilization instead of information technology.
As all Internet developers know, as soon as you build a solid knowledge base in the most current technologies, progress strikes again and your product-specific knowledge becomes obsolete. Technology changes so rapidlyhow can you keep up with it?
At Chicago-based marchFIRST Inc. (formerly Whittman-Hart & US Web/CKS), an Internet professional services company, staying on top of changing Web development technology is one of our challenges. And the Technology Group of marchFIRST's New York office is committed to training its developers in new products such as application servers. Unfortunately, neither managers nor developers were satisfied with the results of traditional classroom training.
The reality of tradition
10 steps to obstacle course success
1. Emphasize technology, not business logic|
2. Exercise all essential skills
3. Create an individual, not a team exercise
4. Involve other functional groups
5. Reinforce company procedures
6. Involve both new and experienced developers
7. Make it platform-independent
8. Use results to provide metrics
9. Gather and evaluate what was learned
10. Motivate your staff to participate
The Technology Group tried hiring outside instructors to come in-house and introduce its developers to new products. But anyone who has tried to clear the schedules of a whole team of busy developers for a few days of training knows how impossible it can be and what a toll it can take on active projects that already have very tight schedules.
Sending developers one or two at a time to off-site training sessions led by the product manufacturers didn't work well, either. There is often a gap between when a new version of a product is released and when the vendor's trainers get up to speed on that version. So classroom training doesn't always cover all the latest features of a product.
Even if the curriculum is up-to-date, the restrictions of classroom training greatly reduce its value to individual developers. For one thing, most developers think best at a keyboard, not a blackboard, and most classroom training involves very little hands-on practice. Also, classroom trainers have to adjust their pace to the slowest learner in the class, which can be very frustrating for experienced developers who want to jump ahead.
Finally, products such as application servers are quite complex and can be used and configured in many different ways. With a class full of developers from very different organizations, trainers can't always cover all the aspects of the product that are relevant to the company's work. At marchFIRST, staff often came back from training without really feeling trained in what they needed to know.
Clearly, classroom training wasn't working. But that didn't remove the challenge of building the team's expertise for upcoming projects. Technology is always marching ahead. The staff needed to prepare themselves for contracts to create new e-commerce sites that were to be built on application servers that some of our developers had not yet used.
Looking for other options
marchFIRST could have avoided training its developers altogether, but that option has even more drawbacks. Throwing your team into the fire and expecting them to learn as they go on a real project isn't fair to the customer or to the developers.
Another strategy is to hire new people constantly, trying to grab up experts in the latest products and technologies. That can be difficult because true experts are hard to find and harder to keep. There is also the added drawback of a lack of continuity for both the team and the customers.
Some companies simply outsource all product-specific work to the product's manufacturer. They may, for example, have consultants from IBM Corp. or BEA Systems Inc., of San Jose, Calif., handle all aspects of an e-commerce site's development that relate specifically to IBM Corp. or IBM's WebSphere or BEA's WebLogic application server.
However, the more pieces of a project you assign to outside consultants, the less continuity and commitment the team has. If the people doing the work do not have a long-term relationship with the client, the project is often not successful in the long run.
Since none of the available training alternatives was acceptable, marchFIRST had to find a way to train its developers that really worked. Representatives from the Technology Group brainstormed requirements for a training solution. They wanted a self-paced program that was flexible enough to use with different products and technologies and a way to train both new and experienced developers. Ideally, marchFIRST wanted a program that would add value to the company beyond the benefits of training and a process that would be fun and engaging for developers.
After a few sessions around the conference table, the Technology Group came up with the idea of an obstacle course. Team leaders from the programming, knowledge management (training), technical strategy, and quality assurance areas participated in strategy sessions to define goals for the course. Participants would use the platform of their choice to develop an applicationin this case, a simple e-commerce sitefollowing specifications developed by leaders in the Technology Group.
The best training option
Just as traditional obstacle courses exercise all different muscle groups, marchFIRST's development obstacle course would exercise expertise in all the elements of programming that its developers must master. Completing the obstacle course would allow developers to learn to use the latest application server, for example, through hands-on practice.
But marchFIRST didn't just want its developers to play with it. The specifications would be carefully constructed so that the process of building the application would exercise relevant Web site development skills that the team would need to use on a real project. These include: directory services (LDAP), cookie management, state/session management, SMTP mail with attachments, HTTPS (secure socket layer encryption), HTTP file upload, ASP (application server pages)/JSP (Java server pages), Servlets, COM/EJB/CORBA components, database access, and XML support.
When the company began planning what the application for the obstacle course would look like, it seemed logical to have developers build one that marchFIRST could put to practical use. Among the possibilities were to create an authentic e-commerce site or an internal program for ordering lunch.
However, real projects require much more than programming practice, which is what the company wanted to emphasize. To build a real-world application, participants would spend too much time on business logic and design, and not enough time on the technical material they need to master.
To make the most of the training time available, marchFIRST streamlined the obstacle course application and created very thorough functional specifications. Participants build what is essentially a performance testing utility. Visually, it is very simplemore like a lab exercise than a slick e-commerce sitebut successfully building it uses all the programming skills needed for the company's most complex Web development projects. Although the specifications are detailed, they could be easily altered to expand or change the technical skills that the obstacle course exercises.
Developers in the Technology Group complete the obstacle course independently, on-site, at their own pace. For an experienced developer, it takes five to seven working days to complete and is typically done between client projects. Each developer selects the platform that he or she wants to use.
How it works
The first few participants used the obstacle course to become familiar with the BEA WebLogic application server or IBM's Web Sphere application server with IBM's Visual Age as the front-end development environment. Participants receive a booklet of functional specifications that guides them in creating a basic e-commerce Web site and provides all the information needed to start building the application.
The specs include a site map for the completed application, menus and user interfaces, the purpose of each Web page, details on when and how the site's database will be updated, how to validate input, and all other necessary functional details.
From the main menu, users can choose to delete a data file, upload a new data file, reset the current database, import data, go to the search menu, or e-mail a data file. Each of those links takes the user to a page containing further related options.
The application allows an XML file to be imported, then propagated out to a database and LDAP store. Simple screens enable the user to run queries and then view performance statistics. For example, the "Search" main page allows a user to enter search criteria to find records within two data stores (SQL database and LDAP). It also allows comparison of search times between LDAP and SQL data stores.
|marchFIRST's "Search" main page allows a user to enter search criteria to find records within the data file. It also allows comparison of
search times between LDAP and SQL data stores.|
Upon submission of search criteria, the two data stores perform the same search, and elapsed time between the two data stores is compared (see graphic above). The application also generates an e-mail that is sent back to the user with the data file as an attachment.
Developers create the application on their own, and then submit it to marchFIRST's quality assurance team for testing. Typically, a senior developer and a quality assurance person review the completed obstacle course application with the developer to discuss areas where the application could be improved. Since the same application can be built using different hardware and software, tests of different solutions on different platforms yield valuable performance metrics that marchFIRST can apply to future projects.
And it really does work
Both participants and senior managers at marchFIRST are enthused about the obstacle course. "Traditional classroom training was never very useful for me because the pace was usually way too slow," says Charles Turano, a senior developer who completed the obstacle course in May 2000. "I much prefer the self-paced obstacle course."
Turano, who has 11 years of Internet development experience, used the course to become familiar with the BEA's WebLogic application servernew technology based on Enterprise JavaBeans that is quickly becoming the standard for e-business development. "This course is a great idea, and its strength lies in its flexibility," he says. "It's specific enough that you can give someone the specs and send him or her off to complete the work. However, the elements of the course could be easily altered to cover certain skills in greater detail, such as expanding the e-mail utility piece of the application."
Development team leader Tarak Chatterjee also completed the obstacle course using IBM's Web Sphere application server, and points out further benefits: "Vendor training classes are strictly product-based and don't always cover exactly what we need to know to do our jobs at marchFIRST. The obstacle course is targeted to exercise the specific skills we use regularly in our business. Since vendor training classes are very formal and time-consuming to develop," says Chatterjee, "often the product itself has new features that the vendor's classes don't yet include."
Chatterjee emphasizes that the obstacle course's flexibility allows marchFIRST to easily add a new "obstacle" to encompass expanded project features. While he thinks the do-it-yourself learning method works well for senior developers who are already adept at the rudiments of programming, he adds, "It may be useful to create some additional guidelines for junior staff or provide closer guidance by mentors as they complete the course so that they practice proper development methods."
Albie Collins, marchFIRST's partner in charge of the Technology Group, says the return on investment is much greater with this course than with traditional training. "Participants learn more in less time and are much more enthused about the obstacle course than with taking classes," says Collins. "Also, since the course can be completed in any development environment, stress tests of the final applications on different platforms yield valuable comparative performance data that we can use on actual projects."
How to make it work for you
Creating, customizing, and testing an obstacle course is time consuming, and refining the program is an ongoing process. You need the concentrated efforts of senior developers and QA staff to create the specs for a course, and the support of management to invest resources in the course's development and testing. The long-term benefits to employees and customers, however, make it a valuable project. Consider the following lessons learned as you create an obstacle course tailored to your own company's developers:
1. Emphasize technology, not business logic
. The object of such a course is to help developers learn new technology and brush up on programming skills they may not have used in a while. Make the most of participants' time by providing them with complete specs that contain all the business process information they will need to create the application and complete the obstacle course.
2. Exercise all essential skills
. Identify the most critical elements of programming that are relevant to your business. For marchFIRST, these included:
Directory Services (LDAP)
SMTP mail with attachments
HTTPS (secure socket layer encryption)
HTTP file upload
Database access, including transaction processing
Be sure the obstacle course you invent requires participants to practice each of the essential skills. Worry less about the usefulness of the final product than about the value of the development process itself. 3. Create an individual exercise, not a team exercise. Even if you typically work in development teams, as marchFIRST does, obstacle courses should be completed in their entirety by individual developers. If participants work in teams, they'll divide up the work according to the expertise of each member, which limits the learning opportunity. Also, the logistics of having an entire development team free for several days are difficult, and would make it less likely that the course would actually be used. If at some point you need a team-building exercise, the specs could be easily modified to accommodate that type of training. 4. Involve other functional groups. While an obstacle course is primarily an exercise for developers, it can also be used by other groups within your company. For example, involving your quality assurance department in load testing and evaluating solutions gives them an opportunity to hone skills, gets even more mileage out of your course, and introduces new employees to other departments. 5. Reinforce company procedures. Especially for new employees, an obstacle course is a good way to get to know how your company works. Develop specs for the course using your usual specification format. Use "real" project procedures for completing and evaluating the work. New employees will become familiar with your internal methods as well as the new technology. 6. Involve both new and experienced developers. While training is often viewed as instruction for rookies, a good obstacle course can be just as valuable for experienced developers. Technology continues to change, which means no one is an expert for long. Also, programmers with several years' experience may have become specialized, and completing the entire obstacle course gives them the opportunity to practice elements of development they may not have used recently. Don't view your obstacle course merely as an orientation tool for recent graduates. 7. Make it platform-independent. Provide complete specs, but don't totally architect the solution. That allows you to use the same obstacle to teach different products and prevents the course from becoming outdated before it's finished. Flexibility is the key to the enduring value of the course. 8. Use results to provide metrics. The product of the obstacle course can be just as valuable as the process. Similar obstacle course solutions run on different platforms can yield valuable metrics that may help you recommend solutions to future customers. Different solutions run on the same platform may also provide valuable performance information. 9. Gather and evaluate what was learned. To make the investment in an obstacle course pay off, don't ignore completed projects. Create a method for reviewing and evaluating solutions, providing feedback to participants, and recording lessons learned for your real-world projects. The completed projects can also serve as a working example in each product or platform and provide platform vs. platform benchmarks. 10. Motivate your staff to participate. Developers should view the obstacle course as a fun opportunity to enhance their skills. Beware of treating the course as a test or as a mandated obligation. Instead, promote the obstacle course as a mini-vacation of sorts, something that is valuable to developers' careers and to the company. Don't make staff complete it on their own time, and don't make it count against their utilization. Your obstacle course should be a refreshing change that lets developers challenge their skills, learn new technology without pressure from a client, and spend some time focusing on development--which is, after all, what they love to do. // Marco Leon is Associate Partner for Quality Assurance in marchFIRST Inc.'s New York office. Ajaz Rana is Senior Architect and JAVA Best Practice Leader in marchFIRST's New York office. They can be reached at marco.leon@marchFIRST.com and ajaz.rana@marchFIRST.com .