Collaboration and Coordination through Basic Internet Tools - CiteSeerX

Collaboration and Coordination through Basic Internet Tools: A Case Study Monica Divitini and Babak A. Farshchian Norwegian University of Science and Technology Trondheim, Norway {monica,baf}@idi.ntnu.no

ABSTRACT In this paper we report on a case study of a distributed software development project supported with basic Internet tools. In particular we focus on how these basic tools have and could be used for supporting the collaboration among the involved parties, as well as the coordination of the distributed activities. We sketch some observations, presenting advantages and disadvantages of using such a basic infrastructure for supporting distributed projects. Finally we highlight some requirements for lightweight groupware systems that we believe could overcome the described drawbacks. Keywords: Distributed projects, WWW, email, CSCW. 1. INTRODUCTION Software development is a distributed activity involving different people with various roles and backgrounds. The distribution is both intellectual (different participants having different competencies and expertise) and, more and more often, also geographical. The availability of desktop computers and the connectivity provided by the Internet have made this distributed nature more evident. Moreover, projects crossing the boundaries of organizations have become frequent not only in research settings but also in the industry. These changes, we believe, arise a set of new intriguing challenges that can no longer be neglected by anybody aiming at supporting software development. Collaboration in particular becomes central and it assumes a slightly different connotation than in traditional software development settings. The power distribution (and consequently the possibility to take and impose decisions and work patterns) does in fact dramatically change in a distributed context. There are two factors that we would like to underline here. First, in more and more situations end users have to (and wish to) be involved in the different development phases. Internet connectivity provides a basic infrastructure for empowering users in situation where their involvement was previously not possible for geographical reasons (see [1] for a discussion). Second, distributed projects often cross the boundaries of various organizations, or involve virtual organizations. In this case it is difficult for example to define overall processes and standards. These two points have also a strong impact on the technological side. First, The involvement of the users implies that some of the participants have such a basic level of technical knowledge that simplicity becomes an important requirement. Moreover, it often becomes unrealistic to look for more advanced collaboration infrastructures than email and the Web. Second, the participation of people from different organizations (or outside any organization) implies that it is highly probable that different local development environments are used. It is often not possible to use one central tool. Deploying a collaboration support tool that is integrated with all the local development tools becomes difficult. Though better technical solutions could be found locally, in many distributed settings what is needed and usable is a collaboration infrastructure that brings people together and coexists with existing heterogeneous tools. Lately many researchers have acknowledged the importance of collaboration in the development process. However, we believe this issue is still far from being solved. Many systems have addressed the problem more in terms of controlling cooperation [2], rather than supporting it. We believe that this approach

becomes problematic especially when considering distributed settings like the one described here. The same problem is faced also in many IS development environments, where collaboration issues have been underestimated or neglected completely [3]. It has however become more and more evident that this assumption is no longer acceptable. Cooperation for example is needed when deciding requirements for the future system, making design decisions, testing prototypes, and the like. However, these forms of cooperation are often realized only through the use of traditional communication media and face to face meetings. During the last three years our institute has been involved in an European project aiming at the development of an Internetbased multimedia information system for supporting collaboration and knowledge-sharing within the European aquaculture community. The project has been running almost entirely on the Internet, using email and WWW as the main collaboration medium. This paper is an attempt to summarize our observations related to the use of this simple Internet infrastructure in a development project. The studied development project can be characterized as a participatory design project in the sense that the development team has been constituted by both end users and developers working together throughout the project lifetime. In addition, early and frequent prototypes were used as a means for stimulating collaboration and improving the quality and usability of the final product. In our study, we wanted to investigate the utility of email and WWW in a participatory design context, especially in building a virtual space for design, and to extract requirements for a more advanced collaboration support tool. When evaluating email and WWW, we have asked ourselves four questions: 1) How well does the virtual space support a context for informal collaboration? A large amount of the collaboration in any design process is informal [4]. Intensive informal cooperation is needed for both users and developers in order to gain an understanding of each other’s worlds, and of the design artifact being developed. 2) How well does the virtual space support a context for design? Informal collaboration alone will not result in a product. A virtual space should also provide support for tailoring a design space, in this way providing the users with a context for design in addition to a context for collaboration. Such a design space should be accessible and understandable to all the participants. 3) How well does the collaboration and design spaces interrelate? The informal collaboration space should be easily connectable to the (semi-)formal design space. The participants should be able to refer to the artifacts in the design space from their collaboration space [5, 6]. Easy reference mechanisms are therefore necessary in order to allow the informal collaboration influence the formal design, and vice versa. 4) How do people coordinate their distributed activities in such an informal setting? How are e-mail and the WWW used for this purpose and which additional support could be provided? In the next sections we will explain in details the settings for the project, and outline some of our observations based on these four points. Afterwards, we will present some design guidelines for a simple collaboration environment that we believe can be used as a starting point for collaborative distributed design on the Internet. We would like to emphasize that the requirements that we propose are not intended for a new development environment, but for a “collaboration layer” that can be plugged in to existing development environments.

This layer can then be used to connect distributed groups together, while allowing them to deploy their existing development tools.

2. THE SETTINGS FOR THE STUDY We have studied a research project (here called Alpha) involving different partners in three European countries. The involved partners were both academic and non-academic. One of the main goals of Alpha was to develop a Web-based distributed multimedia information system for storing and accessing specialized, updated, and high quality information. The project group has been working tightly together in order to outline requirements and test intermediate prototypes of the system. The organization of the project was in a traditional waterfall fashion with many feedback loops. The participants Alpha project team consisted of 41 members, equally distributed among 4 sites in 3 European countries. Four functional groups were officially recognized within the project: • Scientific staff: Constituted of ca. 15 members. This team was in charge of defining the requirements for the target information system. The members came mainly from the aquaculture community. • Technical support: Constituted of ca. 16 members, all computer professionals. These were staff from the computer department, being computer science researchers, last year MSc. students, and administrative. They worked both as developers of the target information system, and as supporting staff for the communication infrastructure used by the members of the project during its development. • Project management board: Constituted of 14 members. These were responsible for contact with sponsors, overall management of the project, and making sure that the deadlines were met. They also played an essential role in finding new customers for the computer system being developed. • Daily management board: Constituted of 8 members. This group was mainly responsible for the daily activities of the project, such as the development of different parts and meeting release deadlines. In addition, there were also multifunctional teams working with different phases of the projects. All these teams included members with both technical and non-technical background. All the teams involved members from different geographic sites. This means that everybody involved in the project had to face the problem of distribution. There was a high amount of turnover among the members, especially in the technical support group. This was partly due to the involvement of students in the programming activities. Competencies and roles Most of the members from the aquaculture community had a modest knowledge of computers. They could use e-mail and WWW, but some of them had for instance difficulties setting up their email accounts, using email lists, editing Web pages, and setting up a videoconferencing session. Moreover, the technical infrastructure at their disposal was minimal. At the other end, members with a good background in computer science had little competency in aquaculture. The roles played by the participants were partly influenced by the developed product. The user role was two-folded, consisting of deciding the requirements for and testing the product. Users ran usability tests, and provided feedback about the user interface of the product. All the participants played also a developer role in that they co-decided the requirements for the system. Technical staff was mainly responsible for implementing the system, but also played an important role in testing the early prototypes. The communication infrastructure Project administration had regular face-to-face meetings every second month. Technical and scientific groups had face-to-face meetings and workshops in connection to each phase of the project. Besides these seldom meetings, all communication was done using email and WWW.

• Electronic mail and mailing lists: As is the case in many distributed settings, email quickly became the standard communication media. A list server was set up in an early stage, and several mailing lists were established. These lists were created by the management in an ad hoc manner according to the needs of each phase. At the end of the project there were 13 active lists being used by the members for different purposes. The most used lists were the technical development and the mixed lists. • The World Wide Web: Throughout the project the members used Web for sharing project information. Moreover, the Web was the platform used for developing the prototypes for the project. Besides a central Web server, each site had its own Web server where they had installed the prototype and published local information. The mailing lists were also integrated with the Web server such that all the messages were made available on the Web. The members were however not able to send email using this Web interface. All the Webbased information was available for all the participants. 3. RESEARCH METHOD The case study presented here reports on a period of approximately two years, from April 1996 to January 1998. The study is based on an initial analysis of raw data collected during the project. This data includes project deliverables, meeting notes and email messages sent to the various mailing lists. Beside the raw data, one of the authors has been participating in the project as a senior technical staff from August 1996 to the end of the project, with heavy involvement in the development of the prototype in cooperation with other project members. Though this participation provides a deep insight into the project and reduces the lack of interviews with the participants, it can have somehow affected the objectivity of the results. Our study differs from more traditional field-studies of work settings in that our data is purely based on electronic communication and archive material. We do not provide any detailed description of workplace activities and work context as for instance in [7-9]. On the other hand, we believe our study provides an insight into the overall distribution problem found in most of the development projects now a day. The only data accessible to the researcher in these settings is normally the electronic communication and archival material. Our study is guided by the idea that developing an information system is a highly flexible process and that most of the collaboration in such projects is informal [10]. However, we have tried to look at the transition from the informal collaboration to the formal design, where we believe the main challenges exist for support tools. This transition is acknowledged by many previous studies of engineers [4, 6, 7, 11-13]. 4. OBSERVATIONS This section presents our observations done after the project was finished in January 1998. We have focused on observations that we believe are important for the type of collaboration support that can be provided for similar future situations. Informal collaboration Mailing lists are analyzed as the main collaboration medium for the project members. The mailing lists were the main forum for providing feedback, discussing design issues, making design decisions, making announcements, etc. They served the purpose of keeping people informed about what happened in the different sites. For most of the members the mailing lists and the Web sites were the only means of collaboration and source of information about the progress in the other sites. Providing feedback Mixed mailing lists used by users and designers proved to play an essential role during the lifetime of the project in collecting feedback for different proposals and prototypes, allowing for the incorporation of different perspectives. The lists increase the awareness of the different needs, priorities and perspectives.

There were mainly two types of feedback. Feedback was collected for evaluating features that had been incorporated into the prototype: “Dear all, Gilbert and I had a look at the prototype pages (http://xxx.xxx.xxx/prototype/) and we have one remark: The keywords structure (two parallel structures, organisms – aquaculture aspects) made by the scientists can not be found back in this demo. Only the organism-part of the keyword structure is available in this demo. Another small (but important) remark: at the homepage there are three flags: the British, the Dutch and the Norwegian. Why the British and not the Belgian?” Another type of feedback was used for informing future decisions. For instance, this dialogue regarding the proposals for the integration of email and WWW: "...Not at this time. Although it should be possible with the Majordomo/MhonArc, I had a problem when archiving only a limited number of messages. Old/obsolete files would not be deleted by MhOnarc. That's why the complete archive is rebuild every half an hour. ..." where the users evaluated the proposal from the point of view of system usability: “I support the proposal from Babak. (If what he described is technically possible, I am not a technician). It makes things easier, and more userfriendly since newsgroups and mailing lists can have the same interface. I think Hendrik will be able to tell if we can make use of the software we use for the project mailing lists.” Another important thing is that feedback was not only provided by the end-user, but also by the technical staff, especially on the future functionality of the system. Access to experts The availability of experts, with domain or technical knowledge, is crucial for the progress of a development project [7]. One major advantage of using email in Alpha was the easy access to different kinds of tacit knowledge. This would have been extremely difficult without mailing lists due to the geographical distribution of the participants. The proper experts were there when a question was asked: “Dear scientists, Is it possible that the same keyword is used in both the aquaculture hierarchy AND in the organism hierarchy? This should have design consequences, so please do react a.s.a.p.” And would answer immediately: “No this is not possible, the same keyword will never be used in the 2 hierarchies.” One limitation of using mailing lists in this way was the fact that mailing lists are neutral with respect to individuals. Questions and requests were sent to the mailing lists with the hope that the proper expert would eventually read and answer them. This limitation gave rise to the problem that some members chose to move their discussions out of the mailing lists, and send personal messages directly to the person they knew was an expert. This in turn prevented other members from contributing with their ideas and opinions. The number of this kind of personal messages sent to some members was eventually much higher than the total number of messages sent to the mailing lists! Resolving design issues The normal practice when an issue was arisen was to send an email about the issue to a mailing list. All the participants could read and publicly comment on the issue in a brainstorm phase. This was very useful for the designers because they could rapidly collect the members' viewpoints without even leaving their desk. This process was also useful for the users because they could get informed about the limitations of the technical solutions, and get explanations on different alternatives. In some cases, one person would be responsible for collecting all the feedback and make a summary of viewpoints, and use this for taking decisions.

Mailing lists caused also some problems. Each issue gave normally rise to sub-issues or other related issues. A major problem that we faced was that people discussed these new issues while still under the subject of the initial email message. This subject was of course not anymore the proper subject for the new (sub-) issue. This became more complicated when the number of threads increased to over 2-3. When having too many concurrent issues under a common email subject, most of the issues were never handled or resolved. The mailing lists did neither give any active support for reminding the members of the existence of the different unresolved threads. Later on, it was also difficult to locate all the messages sent related to a specific issue, which was important for decisionmaking. In this way, much of the potential of using mailing lists was eliminated because of the poor support of "localizing" discussion threads. Decision-making Numerous decisions need to be taken during a development project, regarding both the actual design and other issues. Some decisions are taken locally (for example by the management), others globally. Mailing lists were used regularly for making design decisions. Both users and technicians helped in providing relevant evaluation criteria and information that were useful for all participants: "..[with the solution you propose].this would not be possible. Also I recall something about moderation of the messages in D4 of D5. We would have to drop that then I suppose. I don't mind and in fact am in favor of that approach but can the others agree with that ? ..." The main problem associated with the use of mailing lists was to detect when a consensus is reached for taking a decision. In the considered project, this problem sometimes led to the management taking decisions “on behalf” of the whole project. Moreover, for each decision that had to be taken, a discussion was normally started, making it difficult at the end to understand the final proposed solution, as discussed in the last section. Providing awareness The lack of awareness of the status of the development in different sites caused serious integration problems for the development team. There were also occasions of duplicated effort in different sites. Information about the activities of the local sites was withheld both because it was difficult to maintain status reports periodically, and because the local teams did not know what information was crucial for the other sites. This problem, however, did not exist internally in the local sites, where the members were normally in the same building. Explicit communication was one way of telling others what was happening in the various sites, but often this method proved to be insufficient. The main awareness medium for the project turned out to be the actual prototypes that were developed and made available during the project. See the section on design space later. Synchronous collaboration Though almost all of the collaboration during the project was done asynchronously, there were occasions that would probably benefit from synchronous collaboration support. This was mostly apparent in the level of programming, where the programmers (mostly students) would exchange email messages with short intervals, trying to inform other programmers in other sites about the latest changes they had done. Support for the design space The topics covered in the last sections were related to the informal collaboration in the project team, where mailing lists played an essential role. This informal collaboration is an essential part of every design activity. The power of using mailing lists is mainly because of their informality and flexibility. But informal communication alone is not enough for creating a computerized information system, which is highly formal and in the need of a formal support environment. On the other hand, our observations point to the important role that the mailing lists play in creating the design space of the information system. Event though the discussions seem to be unstructured, they constitute a design space with

interconnected objects, ideas, roles, etc. The informal collaboration was “refined” into design artifacts, which in turn influence the informal collaboration. What follows are some examples that illustrate various attempts to providing a context for the design of the information system. The structure of the design space Due to the complexity of most information systems, the design space is broken down into objects, areas of functionality, modules, documents, etc. These artifacts are used as the external memory of the project team [8] and as a means for coordinating the activities of the participants [14]. The structure of the design space in our case varied depending on the studied mailing list. In a technical list, the discussion threads were related to architectural issues such as the type of middleware, the different modules, the configuration of the system, etc. While in a more general list with different types of participants discussion threads were connected to the functionality areas, such as access rights, user interface, and keyword browser. A discussion in a technical list started with the following message, resulting in a thread with 7 messages. The discussion is related to a module called “convert.pl,” which is also the subject of this thread: “I hope you can comment on this. Now that I can upload new stuff again I would like to know if there have been any changes to convert.pl. I saw that the new keyword database has gotten rid of the underscore characters in the keywords. What are the consequences? Do the input files also use space characters instead of the underscore and if so are there modifications required for convert.pl to upload all the slides again?” Another discussion, this time in a non-technical list, started with the following message, resulting in a thread consisting of 6 messages: “One problem that has been pinpointed by some people, including Alexandra, is how to assign access to objects which are being inserted into the database. I have discussed this with Joern and it seems that we have a fundamental problem there. The problem is rather user oriented than technical… ” Note that this message does not discuss the design of the access right mechanism, but the intended use of these mechanisms, which will of course have implications for the designers. This message illustrates the multiple nature of the design space, where two interconnected structures mentioned here are the functional and the architectural. We believe this is one of the most serious shortcomings of mailing lists that make it difficult to construct a design space, serving the multiple purposes of the different participants. Creating the design space The design space of the project was divided between the mailing lists and the WWW. Most of the artifacts in our case were residing in the WWW, both due to the fact that the prototypes developed during the project were Web-based, but also because the documentation was made available on the Web. Artifacts were created during the project as a result of the collaboration among the members. These artifacts played an essential role during the development process. The essential part of the design space, and specially the cognitive structure of the space in the eyes of most of the participants, was created in the mailing lists as a result of informal collaboration. The role of prototypes Prototypes constituted the most important design artifacts while developing the system. New prototypes were announced on the mailing lists, and all the participants were asked to test them. Prototypes were also used extensively in communicating the functionality in an easy-to-understand manner. Having Web-based prototypes was also important for providing the right context for the development process. Due to their availability, new prototypes were tested in a matter of minutes, and feedback was sent to the lists immediately. We believe this would have not happened if the prototypes were of other nature, such as Windows-based.

Connecting to the design space We observed a close connection between the mailing lists and the external artifacts. Artifacts were mainly brought into the collaboration space through attachments and links in the email messages. The members sent their updates to the design documents as files attached to their messages. New releases of the prototypes and mock-ups of the user interface were made available by sending a link to the proper Web server or Web page: “Hello all. The HTML templates for the Object Visualization of the objects are finished and on-line. You can view them at our site number 2, at the exact URL: http://xxx.xxx.xxx/xxx/demo/objectvisualisation/index.html This index file links to all templates and there are also some notes on the templates in this index file. Please read the notes!” Coordination In the case that we have analyzed it was impossible to define, a priori, a process to be followed during the software development project. The different involved sites, and the members of these sites, were continuously involved in a negotiation process to define and redefine the final product and, consequently, the distribution of activities. Though some roles were defined since the beginning, together with responsibilities and expected distribution of work, many e-mail messages were devoted to the definition of commitments among members (who does what, under which conditions, observing which deadlines, and the like). These commitments were often undertaken in messages where people were talking about other matters. This aspect, together with the distributed nature of the group and the use of alternative communication patterns (e.g., phone calls or e-mail messages exchanged outside the mailing lists) was problematic for two reasons: • It was difficult to get, at each moment, an overall idea of the commitment distribution (i.e., who is expected to do what). • It was difficult to follow the evolution of these commitments, for example to keep track of the deadlines; of the tasks that were completed, possibly waiting for an approval; of the necessary renegotiations and the like. Despite these problems, communication proved to be an acceptable way to coordinate ad-hoc processes. However, during the life time of the project some processes became recurrent, and pattern of actions started to emerge. Examples of these recurrences are handling feedback and taking decisions. This seldom led to the development of specific procedure and these patterns were never formalized, probably because of the lack of appropriate tools. This lack was problematic for the group, often leading to the redefinition of appropriate coordination patterns that others, possibly in other sites, had already developed and experienced. In addition, particularly considering the distributed nature of the analyzed group, it was difficult for the members of the project to gain an overall understanding of how different processes were connected to each other and how they could benefit from these connections. Technical issues The project team was highly sensible to the type of technology used. Complicated technology for communicating ideas and results was not always successful. An example of this appeared when the development team programmed a Java module in the prototype. It turned out that because of compatibility problems some members could not view this part of the prototype. This resulted in a breakdown in the feedback cycle, and increased dissatisfaction among participants with low technical knowledge. The same thing happened when the user interface design team started using animation programs for visualizing their screen shots. These programs required the installation of new ”helper” software on the client site. Since some of the members did not have access to necessary technical assistance for installing these helper programs, they could not view the screen shots. 5. DESIGN IMPLICATIONS Mailing lists proved to be useful for informal collaboration. But the unstructured nature of the mailing lists makes it

difficult to provide support when the informal collaboration takes on some structure, which is a natural consequence of creating design artifacts of a more formal nature. Our design implications suggest a system that is able to preserve the informal nature of this collaboration using mailing lists, but which improves the support in the following directions: • Support for structuring the collaboration: Email lists provide flat communication spaces. Our experience shows that attempt to isolate discussion threads is important. There should exist mechanisms for structuring mailing lists dynamically according to the current discussions. It should also be possible to connect various mailing lists to each other, and to navigate in the communication space created by the mailing lists. Providing awareness of what is happening in the project is also an important part of collaboration support that we mean is missing from mailing lists. In addition, a support should be provided to identify commitments and their evolution, as they emerge from the various message exchanges. The Language/Action Perspective [15] with its focus on the pragmatics of language provides an interesting background, but its application is problematic, particularly in highly distributed and informal settings. • Support for the structure of the design space: The design space of an information system is not flat, and consists of numerous artifacts located in interdependencies and hierarchies. Some of these artifacts are abstract, while others are detailed and tangible. There is a need for easily creating and structuring (connecting, dividing, etc.) design artifacts of arbitrary content and format. • Support for connecting to artifacts: The majority of the discussions carried out during the project refer in some point to artifacts in the design space. These artifacts play an essential role as external memory for the group of designers working together [6]. A support environment should therefore provide mechanisms for connecting these artifacts to the proper discussions. • Support for coordination and negotiation: In distributed settings it seems important not so much to make available a language for modeling (and automating) an overall process, but rather the possibility to (co)define smaller local processes and connect them together in a flexible way. Though automation of certain global tasks can be definitely useful, that does not seem to have the highest priority in distributed settings. • Active support: software products are normally very large. The number of the artifacts (e.g., modules, documentation, test report) involved can easily get up to the order of several hundreds, and the number of issues raised and resolved is accordingly large. No matter how sophisticated mechanisms for navigation and access to the artifacts are, there will be a need for active support from the system. By active support we mean that the system will automatically provide the users with proper information according to the task under performance. One such active support that is highly desirable is that of sending notifications of unresolved discussions and issues. • Additional facilities: The system should provide the possibility to “plug in” different facilities, as for example for representing the distribution of expertise, supporting virtual meetings, and voting. In addition to these requirements, simplicity and openness are also two generic requirements that prove to be of crucial importance in such a context. 6. CONCLUSIONS We have presented a case study of a two-year period of a distributed IS development project. The case study has resulted in a set of requirements for a support system, a prototype of which is currently under development. We believe that a useful collaboration support tool should fulfill all of the requirements outlined here. In particular, the requirements of simplicity and openness are of great importance due to the heterogeneous nature of the studied project, both in terms of local technical infrastructure, and the diverse background of the participants. Our future work is to fully realize the requirements outlined here in form of a prototype, and to test the prototype in several student projects. The results from these studies will then be

used to further refine the prototype. As mentioned in the introduction, our goal is not to develop a system substituting the existing tools for supporting software development, but rather to develop a “collaboration layer” for connecting distributed groups (that possibly use different specialized tools). It is therefore in our near plan to study the integration of our prototype in conjunction with an existing CASE tool. 7. ACKNOWLEDGMENT We thank all the members of the Alpha project for providing us with the material for this case study. Part of this research is sponsored by Andersen Consulting Forskningsfond, Norway. 8. REFERENCES [1] Divitini, M., B.A. Farshchian, and T. Tuikka, eds. Proceedings of the CSCW'98 Workshop on Internet-based Groupware for User Participation in Product Development. Seattle, Washington, USA. [2] Godart, C., Cooperation Control in PSEE, in Software Process: Principles, Methodology, and Technology, J.-C. Derniame, B. Ali Kaba, and D. Wastell, Editors. 1999, Springer: Berlin. [3] Sande, A.M.T., Support for collaborative design in contemporary CASE tools - framework and evaluation, master thesis. Department of Computer and Information Science. 1998, Norwegian University of Science and Technology: Torndheim. [4] Bucciarelli, L.L., Designing Engineers. 1994: The MIT Press. [5] Dix, A., Challenges for Cooperative Work on the Web: An Analytical Approach. Computer Supported Cooperative Work: The Journal of Collaborative Computing, 1997. 6(2-3): p. 135156. [6] Reeves, B. and F. Shipman. Supporting Communication between Designers with Artifact--Centered Evolving Information Spaces. in Proceedings of the Conference on Computer--Supported Cooperative Work, CSCW'92. 1992. Toronto, Canada: ACM Press. [7] Curtis, B., H. Krasner, and N. Iscoe, A Field Study of the Software Design Process for Large Systems. Communications of the ACM, 1988. 31(11): p. 1268-1287. [8] Flor, N.V. and E.L. Hutchin. Analyzing Distributed Cognition in Software Teams: A Case Study of Team Programming During Perfective Software Maintenance. in Empirical Studies of Programmers: Fourth Workshop. 1991: Ablex Publishing Corporation. [9] Grinter, R.E., Supporting Articulation Work Using Software Configuration Management Systems. Computer Supported Cooperative Work: The Journal of Collaborative Computing, 1996. 5(4): p. 447-465. [10] Kraut, R.E. and L. Streeter, Coordination in Software Development. Communications of the ACM, 1995. 38(3): p. 69-81. [11] Moran, T.P. and J.M. Carroll, eds. Design Rationale: Concepts, Techniques, and Use. . 1996, Laurence Erlbaum Associates. [12] Olson, G.M., et al., Small Group Design Meetings: An Analysis of Collaboration. Human-Computer Interaction, 1992. 7(4): p. 347-374. [13] Rittel, H., On the Planning Crisis: Systems Analysis of the 'First and Second Generations'. Bedriftsøkonomen, 1972. 34(8): p. 390-396. [14] Schmidt, K. and C. Simone, Coordination Mechanisms: Towards a Conceptual Foundation of CSCW Systems Design. Computer Supported Cooperative Work: The Journal of Collaborative Computing, 1996. 5(2-3): p. 155-200. [15] Winograd, T. and F. Flores, Understanding Computers and Cognition, 1986. Ablex Publishing.