Supporting Developers’ Teamwork from within the IDE

Anja Guzzi

Promotors: prof.dr. A. van Deursen (TUD) and prof.dr. M. Pinzger (University of Klagenfurt, Austria)
Technische Universiteit Delft
Date: 30 March, 12:30
Thesis: PDF


Teamwork is fundamental in the production of software, because of the substantial complexity of software systems and the urge for fast time-to-market. Nevertheless, the difficulties in coordinating developers and teams and in making them collaborate are among the main reasons why the software industry has always been in crisis. Different researchers have repeatedly confirmed this problem, by conducting many studies in different contexts.

Achieving good teamwork is difficult for many reasons, for example, because communication in natural language is ambiguous, human memory cannot remember all of the project’s details, and keeping track of what everyone is doing, even in a small group, is hard. These issues are exacerbated if developers are distributed across the globe, or even if they simply keep their office doors shut or work in different floors of a building.

Supporting teamwork is one of the most difficult-to-improve aspects of software engineering. Researchers have built theories on teamwork for software projects and have proposed a number of solutions to the practical challenges faced during collaborative software development. In particular, given that developers spend most of their time in the software environment in which they read, write, test, and design source code (also called integrated development environment—IDE), researchers have proposed a number of approaches to support teamwork in the IDE. Prominent examples (such as Jazz and Mylyn) are fullfledged platforms built on top of the IDE, which are aimed at transforming it into a comprehensive collaboration tool.

In this dissertation, we work in this context: developers’ teamwork in the IDE. We consider the IDE because it also allows us to better connect with the final product of the development effort (i.e., the source code). We work toward creating lightweight additions to the IDE, instead of heavyweight ones, because the latter may disrupt the development workflow, habits, and development process in place in a team, and they often require a steep learning curve. We address both collocated and distributed development settings, because what supports teamwork is not limited to one scenario.

Overall, the goal of our work is to devise lightweight IDE additions that can be seamlessly integrated in the development workflow of a variety of teams and that provide additional effective support to developer’s teamwork, while requiring little learning time.

We structure our work in three parts: The first part investigates (through two studies) how developers currently experience teamwork, to pinpoint important pain points and understand the leeway for improvement; the second and third parts start from the results of the first one and explore two approaches each to deal with one of the key aspects of teamwork: information sharing.


How do developers experience collaboration in teamwork?
To better understand how to improve teamwork support in the IDE, we first investigated the current practice of industrial developers’ working in teams. Although developers are able to find effective workarounds for situations considered as problematic in literature, they find it difficult and time-consuming to correctly understand the changes to source code made by other people; and they are especially frustrated when these changes are done by a project mate, since he could have informed them.

How is information shared in open source software projects?
In the second research question, we investigate the case of open source software development (OSS). We investigated the communication channel that is considered in literature as the hub of project communication in OSS projects: the development mailing list. We found that communication is currently scattered across several types of channels, such as issue repositories, code commits, and face-to-face talk. As a result, the mailing list seems to have lost its role of main communication channel in favor of the issue repository, which is closer to the code and offers more structured communication than noisy emails.

By answering the first two research questions we learned that: (1) knowledge generally accepted in previous research should be verified, (2) information sharing is vital to support teamwork, (3) developers could retrieve part of the information they need, but it is not easily accessible, and (4) tools to support teamwork should be connected to source code.


How can we expose existing information to support teamwork?
To expose information that is already available, but not easily accessible in the IDE, we created two IDE extensions and evaluated them with users. cares is our first addition: It gives information about who one should contact to ask information about a specific piece of code. It shows contacts’ information, their availability, and their photo; cares proved to be effective and useful to developers. Bellevue, our second addition, improves the code change support offered by the IDE: Not only does it keeps visible what changed since the last update of the local code, it also seamlessly integrates code history in the editor and adds contact information similarly to cares. Developers rated the design of Bellevue very positively.

How can we aid information creation to support teamwork?
Part of the information that would be useful to developers is neither recorded nor shared. For example, when they spend time understanding a piece of source code, developers do not usually leave any trace, so their precious insights are lost once the task is completed. We argued that this kind of information would be very valuable to support teamwork and we devised two IDE extensions for this task. Pollicino is a simple, lightweight solution based on sharing bookmarks in the code. Our experiment showed that it can be effective to generate information useful for other team members. James is an approach that lets developers share their comments in form of (Twitter-like) brief messages and automatically records developers interactions with the IDE. In an initial study with developers, we showed the feasibility of our approach and that developers are interested in having it.

By answering the last two research questions we learnt that: (1) Lightweight IDE extensions, which require neither huge implementation effort nor long learning time, can support teamwork effectively, (2) showing developers’ photos close to source code increases developers’ sense of community, (3) popular IDEs have poor support for dealing with code changes, but this can be improved, and (4) tools can help team members creating additional information to support teamwork, without requiring major efforts by them.