A Tool Allowing Software Engineers to Automatically Determine if Remote Team Members are Stuck Jason Carter Department of Computer Science University of North Carolina at Chapel Hill
[email protected]
Prasun Dewan Department of Computer Science University of North Carolina at Chapel Hill
[email protected] recent research results have shown that a teams' productivity increases when engineers help each other. In the first study, comparing co-located and distributed software development, Herbsleb found that co-located teams were more productive then distributed teams primarily because co-located developers were more apt to help each other finish their tasks [2]. In the second related study, Teasley et al. found that the productivity of a team located in a single “war-room” was much higher than that of one spread out in different cubicles. A major reason was that if someone was having difficulty with some aspect of code, another developer in the war-room “walking by [and] seeing the activity over their shoulders, would stop to provide help” [3]. The studies above imply that developers do not explicitly ask for help, even when they could use it, and that the greater distance between them and potential helps, the more difficult it is for the latter to determine if the former need help. A perfect helper tool could make the distance between remote developers disappear. The rest of this paper describes a first cut version of such a tool.
ABSTRACT
Previous research shows that (a) the software productivity of co-located programmers increase if they help each other, and (b) programmers help remote developers much less than co-located ones. We have built a tool that allows software engineers to automatically determine if remote team members are stuck. This video takes the user on a tour of the tool, illustrating both the issues raised by its design and our preliminary approach to resolving these issues. Author Keywords Context aware computing, machine learning, help ACM Classification Keywords
H.5.3 Group and Organization Interfaces: Computersupported cooperative work. General Terms
Human Factors INTRODUCTION
One of the problems of distributed software engineering is that it is difficult to determine if remote team members need help. This video motivates and describes a tool that automatically determines if a programmer is stuck and communicates this information to interested team members. Details of two algorithms for determining programmers’ status are presented in [1]. Since the paper was submitted, we have built a tool around these algorithms. The video shows the tool in action. In the rest of this document, we describe the various sections of the video.
TOOL DESCRIPTION
The tool is integrated into the Visual Studio and Eclipse programming environments. For the purposes of this video, we illustrate the tool in the Visual Studio programming environment. Therefore, when Rob is having difficulty, the tool can detect this and show him a ‘slow progress’ status notification (Figure 1). However, a ‘slow progress’ status could hurt Rob’s ego. To avoid hurting Rob’s ego, we allow him to customize his status (Figure 2). Rob may prefer a status that says ‘complex code’ or he may prefer to see a color indication of his status (Figure 3a) instead of a text indication (Figure 4a). If Rob forgets the meaning of these colors, he can use a legend (Figure 3b).
SCENARIO
The video motivates the tool using the following simple scenario, which is used as a running example. Rob is a new software engineer working in Oregon and Alice is his mentor, but she works in California. While Rob is writing code, he becomes stuck and cannot make any progress. A helper tool magically detects that Rob is having difficulty and informs Alice. Immediately, Alice calls Rob and helps him solve the problem.
Figure 1: Notification that alerts developers of a status change.
ISSUES AND RELATED WORK This scenario raises several issues. In particular, is it a good use of Alice's time to help Rob? After all, while she is helping
him, she cannot do any of her work. As it turns out, two Copyright is held by the author/owner(s). CSCW 2010, February 6–10, 2010, Savannah, Georgia, USA. ACM 978-1-60558-795-0/10/02.
629
Figure 2: Customization interface that allows developers to change ‘slow progress’ status.
To visualize the algorithms used in the tool, we demonstrate another tool that replays developers’ actions. This tool reads from Rob’s logs and mimics his actions. It also shows when Rob was having difficulty. To further visualize these algorithms, we graph and briefly explain Rob’s programming behavior shown in Figure 7.
a) a) b)
b)
Figure 3: a) A color indication of developers’ status. b) A legend that shows developers the meaning of the colors.
Figure 4: a) A text indication of developers’ status. b) The buttons developers can use to change their status before it is reported to their buddy list.
In this graph, the x-axis is the amount of time Rob spent programming time and y-axis is the percent for each of Rob’s actions. For example, the edit percentage is the number of edits divided by the sum of all of Rob’s actions including editing. When Rob was having difficulty his edit percentage decreased while his navigation percentage increased. The tool recognizes this decrease and predicts that Rob is having difficulty.
Notifying Rob of his status is only helpful to train the tool to recognize his status. Alice can become aware of Rob’s status through her Google Talk buddy list which is also integrated into the Visual Studio programming environment (Figure 5). Since Alice is his mentor, Rob’s trust her and he also trusts close friends. However, there are other developers on Rob’s buddy list who may judge him. These judgers assume Rob is incompetent because of his ‘slow progress’ status which causes Rob to lose respect in his team. To avoid losing respect, Rob can block judgers (Figure 6). This feature is also used in Google Talk and other IM clients to block users. However, Rob may not want to block some judgers. For example, Rob’s boss or cube mate may be judgers. Judgers know that they are blocked because the buddy who blocked them will no longer appear on their buddy list. This could cause hostility in Rob’s team. Therefore, a better alternative for Rob is to change his status before it is shown to users on his buddy list (Figure 4b).
Figure 5: The Visual Studio environment extended to show a user’s Google Talk® buddy list.
Figure 7: Rob’s programming activity over an hour. REFERENCES 1. Carter, J. and Dewan P. Are You Having Difficulty?
In Proc. CSCW 2010.
Figure 6: The check mark indicates that user Jason Carter is blocked.
630
2.
Herbsleb, J.D., et. al. Distance, dependencies, and delay in a global collaboration. In Proc. CSCW 2000.
3.
Teasley, S., et. al.. How does radical collocation help a team succeed? In Proc. CSCW 2000.
