Developing Web-Based Content in a Distributed Environment
The rise of the Web has focused distance learning efforts on well-designed, Web-based interactive examples for teaching complex issues. Creating a virtual textbook of these dynamic examples demands a broad scope of qualifications of the development team, experts in subject matter, graphic artists, software engineers who cooperate with domain experts to program the simulations and interactive examples, and copy editors to check the text. To keep the whole process organized and on schedule, the project manager employs Web-based tools (WBT) and organizational techniques.
Here, we explore how to organize global development teams using best practices and the tools that support collaborative WBT development. Our experiences are mainly based on the Teach/Me and the Coimbra project developed at the Vienna University of Technology under the supervision of Dr. Hans Lohninger and his team and, during the past year, on the experiences of teams of software developers in Austria and at Beloit College in Wisconsin.
Organizational Best Practices and Tools
WBT projects require a core team working in close cooperation, and an extended team—organized as satellite teams—that do not require such tight integration. Ideally, members on a team should be located in the same (or a nearby) time zone.
Core Team
The core team develops the basic foundations upon which the extended teams can build. For the Teach/Me project, a class hierarchy provided a set of methods for the simulations, or interactive examples, created by the programmers in the extended team. Acting as a framework, the hierarchy also provided the functionality for a common look and feel to the interactive examples and integration into the entire system architecture—for example, a common cache and encryption for all content.
The core team is also in charge of the product, gives specific assignments to satellite teams, and manages the requirements. Today, any implementation in which every unit receives only the information required to complete its mission—without understanding the big picture—is not conducive to software development, especially Web-based training software. Whether the team is working at one location or many, an open door policy can facilitate close cooperation. Two tools that support the open door policy for globally distributed teams are ICQ (or similar programs such as Microsoft's Instant Messaging) and an IP telephone (such as BuddyPhone or NetMeeting).
ICQ shows which of the team members is currently online and whether his or her screen saver has been activated. A simple mouse click can start a chat or transfer files. The IP-based telephone can integrate into ICQ, and when the phone is set to auto, it can accept incoming calls without the person called having to establish a voice connection. This program is useful for discussing topics too complex for an online chat session. The bandwidth requirements are moderate (approx. 60kbits/sec), but the real disadvantage compared to phone calls is latency (~0.5 -1sec).
As the extended team uses the framework, design and implementation errors can occur. Programming in pairs, a principle enforced in Beck's Extreme Programming, helps to increase productivity, reduce error, and make the generated code easier to understand.
Pair programming requires even more interaction than the open door policy. Voice communication can be established via an IP phone. However, both programmers have to see the same screen and need a way of directly interacting with the development environment. We have tested PCAnywhere and Microsoft's NetMeeting. Unlike NetMeeting, PCAnywhere offers the possibility of controlling all functions of the remote PC without the second programmer being present. Both users—the person using the PC that runs the development environment and the PCAnywhere server, and the person interacting with the remote PC—can program as if they were sitting in front of the same computer. Depending on the host's resolution (60kbit/s seems to be the minimum requirement) at least twice that bandwidth is required for more efficient work.
Extended and Satellite Teams
The extended team develops content, such as interactive examples and page content, independently from the core team. Members of the extended team usually form small satellite teams for working more well-defined problems. For example, when developing WBT software for a statistics course, one satellite team may work exclusively on linear regression. Keeping content developers in satellite teams working on distinct parts facilitates version control. Within a team, collective ownership of code or content may be advisable, but we suggest that internal organization be left to the individual teams.
In addition to creating the content, the extended team is also responsible for the larger picture—integrating the interactive examples with the textbook, for example, through hyperlinked pages (see example, left).
For the communication of technical details, the teams rely on a well-maintained Web page and project-related newsgroups until the basic functions of the WBT system are implemented. Then the system itself can be used for all communication processes. Discussions about the content can be very effective when an annotation function is used; this should be available in every WBT system. Because most code documentation is written in HTML format, the same annotation functions can be used to trace bugs and to make improvements in the code.
System Integration
The challenge for satellite teams is to maintain integration with the whole team and to commit to the whole project. Without commitment, deadlines tend to slip, and being globally dispersed greatly increases the risk that the whole project disintegrates. This risk is especially high if team members do not work full-time on the project, which is often the case with WBT software, since domain experts are often university professors who cannot work full-time on a single project. Commitment to the entire project—the larger picture—also promotes better integration of the content that has been contributed by each of the satellite teams.
With the team members widely dispersed, it may be tempting to develop content and technical infrastructure independently, and then to integrate the system at the end of the project. We cannot overemphasize, however, the importance of always having an executable version. Most convenient for this effort is a virtual private network and a commercial code repository such as Microsoft's Visual Source Safe. However, for a small project, a simple FTP server might also suffice.
Project Completion and Continuous Maintenance
Once all content has been developed and the system is stable, the workload decreases. However, unlike traditional paper-based learning aids, WBT content requires regular updates and maintenance. In the years following initial launch of the project, the programmers who maintain the interactive examples—mostly students hired temporarily—will change. The authors, who tend to be university professors who have been teaching the courses for several years, will likely remain.
Our experience in distributed WBT projects over large geographical distances has shown the effectiveness of traditional organizational techniques that have been modified to be compatible with existing communication tools. Most of the daily work can be done using a set of free or inexpensive tools, creating an affordable system for globally distributed project teams. However, we also feel that the Internet cannot fully substitute for face-to-face interaction; to successfully manage a team, we encourage all team members to meet at least once during the development phase of the project.
