Information Needs in Collocated Software Development Teams by Ko et al.

What information needs exist and how severe are they?
The questions below has been organized under 7 headings and the frequency and importance of the questions can be viewed in the figures below.

1. Writing Code
c1) What data structures or functions can be use to implement this behaviour?
c2) How do I use this data structure of function?
c3) How can I coordinate this with this other data structure or function?


2. Submitting a change
s1) Did I make any mistakes in my new code?
s2) Did I follow my team's conventions?
s3) Which changes are part of this submission?


3. Triaging bugs
b1) Is this a legitimate problem?
b2) How difficult will this problem be to fix?
b3) Is it worth fixing?


4. Reproducing the Failure
r1) What does the failure look like?
r2) In what situations does this failure occur?


5. Understanding behavior
u1) What code could have caused this behaviour?
u2) What's statistically related to this code?
u3) What code caused this program state?


6. Reasoning about design
d1) What is the purpose of this code?
d2) What is the program supposed to do?
d3) Why was this code implemented this way?
d4) What are the implications of this change?


7. Maintaining awareness
a1) How have resources I depend on changed?
a2) What have my coworkers been doing?
a3) What information was relevant to my task?

Figure 1: Types of information developers sought with search times, percepted importance, availability and accuracy.

Figure 2: Type of information developers sought and the frequency and outcomes of searches, and sources. Common sources are in bold.

Coordination in Software Development by Kraut and Streeter

What characteristics of software development do cause coordination problems?

1.) Scale
Software systems are usually extremely large and requires a high level of coordination. This level of coordination is very difficult to obtain in large companies and project teams. Projects of this scale usually leads to specialization groups and a division of the team according to geographic, organizational and social boundaries. These barriers and specialized groups reduces the willingless for interoperability of the team and limits the level of experience each member gains.

2.) Uncertainty
Uncertainty is also a large factor and also increase the problems generated due to the large scale. Since most software systems are unique with none or few previous implementations and applications in the specific field it leads to uncertainty. Furthermore, the functionality requirements of a software system often change during the development phase as the users realize what the software is capable of. Specifications are also usually unclear or incomplete due to limited availability of specific domain knowledge. Sometimes it is necessary for developers and achitects to make discission without having all the information readily available due to low levels of coordination. Lastly, software uncertainty is also caused since different subgroups involved in its development often have different views on what the software should be capable of.

3.) Interdependence
Software systems requires precise integration of the different components and modules. Unexpected problems may occur due to unanticipated interaction between the software modules and can have disastrous consequences.

4.) Informal communication
Several tools have been developed over the last couple of years to improve the productivity of the individual programmer, however these tools does not specifically address coordination problems. Informal coordination such as personal, peer-oriented and interactive communication may be necessary to face problems associated with uncertainty. However, as mentioned above a large cause for uncertainty is the scale of software systems. This large scale makes it difficult for informal communication to occur. Furthermore, in the situations in which it can occur, speach which is the primary medium for this type of communication, may be too imprecise to describe the tight coupling necessary between different software modules.

Groupware and Social Dynamics: Eight Challenges for Developers

The huge software markets created by standalone PC's used to be restricted to single-user applications. However, this changed as computers became interconnected through networks which opened the markets for group applications. The main problems arises from the fact that the biggest interest in groupware development is found among developers and users of commercial off-the-shelf products, who used to focus om single-user applications.

In general, an organization may adapt to a large computer system, but a small application program must adapt to the organization. Groupware is seen as a small application in comparison with MIS software. Due to the social and political factors at work in group settings, achieving groupware acceptance is much trickier than single-user product acceptance.

The eight challenges for groupware developers are:

1. There exist a disparity in the work and benefit of different users - Electronic calendar example
2. A critical mass for groupware is required and according to the prisoner's dilemma if everyone furthers his own goal the critical mass will not be reached.
3. There is often a disruption of social processes that can lead to rejection of the groupware. It is extremely important for groupware developers to work with representative users whenever possible.
4. Exception handling - Most systems requires ad hoc solutions and it is difficult to implement these features within the groupware.
5. Unobtrusive accessibility - Infrequently used features must not obstruct more frequently used features. However, they must be known and accessible to users.
6. Difficulty of evaluation - It is difficult to relaibly capture complex but important social, motivational, economic and politicial dynamics.
7. Failure of intuition - Good intuition for multi-user applications is unlikely to be found anywhere in a product development environment. Experience is based on single-user applications.
8. The adoption process - Consultation is not packaged with shrinkwrapped software and groupware adoption is a much more complex process than that of of-the-shelf wordprocessors.

The following methods may help in overcoming behavioural and social challenges.

• Extend the use of single-user applications by adding groupware features
• Find niches where existing groupware succeeds
• Build on projects that have fared better in the past
• Find ways to provide direct benefits for all group members
• Educate managers and developers about groupware

Belated Readings: Week 3

Computer-Supported Cooperative Work: History and Focus - Jonathan Grudin

What factors and developments led to the establishment of the area of CSCW?
Started with office automation where it was tried to extend word processors and spreadsheets to support groups. It was found that technology alone was not enough, and that it would be necessary to research group dynamics and how people work in groups in order to create successful groupware application. Initial developments consisted of desktop conferencing, videoconferencing and email. Typical related studies that supported the establishment of CSCW were CAD/CAM, CASE and MUDs.

What are the differences between US and EU research traditions in CSCW?

US	Europe
Small-system/product development	Large-system/internal development
R&D sponsored by Computer industry, research labs and University; R&D more intertwined	Mostly Government sponsored
Focus on Experimental, observational and sociological data	Focus on large-scale systems development
Others build technology and they look for ways to use it	Driven by philosophy, social, economic, or political theory
Empirical:Experiments by social psychologists looking at group activity among teams of students	Contributions: Explicitly grounded in the writings of philosophers, social theorists and economists.

Collaborative Computing: The Next Millenium - Jay Nunamaker

What does Nunamaker tell about the role of anonymity in groupware systems?

Traditionally the requirements gathering process documented each person’s contribution every step of the way. This stifles both innovation and criticism, since no one wanted to get a reputation for rocking the boat. To prevent this stifling of ideas Nunamker suggested anonymity during the idea-gathering phase of meetings. The anonymity was obtained by allowing each person the use of a computer during the meeting to type their contributions to the meeting, which appeared, anonymously, on everyone else’s screen.

This allowed people who tended to remain silent in meetings, from shyness or intimidation, could now share their ideas freely. It also avoided constant bickering and shooting down of hostile participants ideas.
The net effect of these meetings was to generate more and better ideas faster .

Unfortunately, the very anonymity that allows freedom of expression can also be abused. To avoid this type of chaos, the anonymity should be conditional. There are times when you want participants to be anonymous and times when you don’t.

Belated Readings: Week 2

Distance Matters

What are the major differences between co-located and distant work? Why does "distance matter"?

When trying to bridge co-located and distance located workgroups, it is necessary to realize the key characteristics of co-located teams. These are:

1. Rapid Feedback
2. Multiple Channels
3. Personal information
4. Nuanced information
5. Shared local context
6. Informal “hall” time before and after
7. Co-reference
8. Individual control
9. Implicit cues
10. Spatiality of reference

Groupware in the market currently only supports characteristics 2, 3, 4 and 6 of the above list, and even then, it is supported poorly. Future groupware would at least be able to provide most of these characteristics; however the following factors will continue to provide resistance

1. Lack of common ground, context and trust
2. Different time zones
3. Culture differences


What do you think: will it be possible to make distributed teams as efficient as collocated ones in the future?

Within the global environment today, it is necessary to work across countries and time zones. Unfortunately, we are forced to accept the current solutions. In my opinion, distributed teams will never become as efficient as the co-located teams. It would rather be necessary to look at the added value provided by distributed teams, which will force the work environment to accept these collaborative solutions.

Objective

This blog will mainly be used to post answers to the discussion of certain scientific papers made available through the CSCW class.