Dispersed Software Teams Call on New Aids for Collaboration

The need for distributed enterprise teams to secure both their process and content arises, perversely, at exactly the same time that developers are more likely to be working on wireless laptops in a number of locations. This makes it all the more essential to decide on the optimal extent of needed protection—not merely of code but also of project objectives and timing that may be highly sensitive information—and the means of achieving such protection.

VPNs should be used on all remote clients, wireless or otherwise. In addition, encrypted file storage on portable computers is not an excessively paranoid measure, considering the frequency of laptop computer theft or misplacement.

As always, though, the best security is limiting access to those with actual need to know—even though this means putting more effort into defining roles and administering access permissions using technologies such as Sun Microsystems Inc.s Java System Communications Suite. New security features in that offering, including role-based administration and end-user message signing and encryption, were unveiled at the RSA Conference in San Francisco last month.

Another irony is the need for scalability, a word thats long been a mantra for applications themselves, but that must now also become a key consideration in the processes that build them. Collaboration systems may easily grow in an ad hoc manner—for example, between two major development sites for a single project—only to become hopelessly unwieldy when the number of entities and locations increases, perhaps to half a dozen or more. Management tools that worked at small scale—a weekly teleconference, an e-mail distribution list—may fail to meet the needs of multiple projects and of participants with varied and specialized disciplines and interests (not to mention widely separated time zones).

Long-range results will be much better, even though initial efforts may seem excessive, if a collaboration environment is built on the assumption that collaboration will quickly become the norm—that team-based development will quickly spread to address an ambitious slate of projects involving different and overlapping sets of resources on intersecting (or even colliding) schedules. Collaboration management systems should be designed to permit the convenient definition of new projects, giving each its own work space for sharing work products and communicating plans and activities. In principle, this should involve no more effort than giving a new employee a user account and e-mail address upon joining a development team.

The system must also anticipate and address orthogonal requirements—that is, the need to allocate a developers time among more than one project as well as integrating that developers availability and effort into the schedule for any single project.

Any development manager should consider the impact of cultural differences among collaborating teams that are based in different countries.

In one study performed in 2002 by researchers in Japan, an electronic bulletin board (dubbed TransMail) enabled developers to post messages in English, Japanese and Korean, with automated translation services in the background seeking to make the differences transparent to participants.

A brief transcript from the resulting published paper, "Open Source Software Development with Your Mother Language: Intercultural Collaboration Experiment 2002," suggests the awkwardness that can arise—and the information that gets lost or, worse, distorted in translation—despite state-of-the-art translation technology.

Even accurate translation of what is said may fail to reflect what is meant. An American manager might respond, for example, to the Japanese speakers statement during the excerpted exchange reproduced on Page D4—"It is very difficult"—with a comment such as, "Well, what are you waiting for? Get to it." This would miss the nuance that the Japanese equivalent of "it is difficult" often is intended as a polite way of deflecting a request as one that cannot be granted.

A system thats designed to aid direct communication among team members may fail to achieve its goals when different cultures favor different degrees of directness. Building the tool set is therefore only the beginning of building a collaborative process.

Technology Editor Peter Coffee can be reached at peter_coffee@ziffdavis.com.

Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.