ICSE’22. Anastasia Ruvimova, Alexander Lill, Jan Gugler, Lauren Howe, Elaine Huang, Gail Murphy, Thomas Fritz

Background

Developers are accustomed to their friends and family viewing them as magicians, brewing up concoctions of 0’s and 1’s from behind the fortress of their screens. In fact, software development can seem a bit magical even to the magicians themselves, and to their managers. In an effort to grant some method to the magic, software projects are typically broken down into smaller tasks, which are distributed among developers, and progress is measured through burndown charts which combine everyone’s DONE’s and TODO’s. Thus, when asked how they define productivity, many developers answer something like a ratio of “tasks done” versus “tasks assigned”. Indeed, both in research and practice, developer productivity is often viewed on this individual scale.

Challenge

However, software projects are more than just a sum of every developer’s progress. These projects are often large and complex, requiring a great deal of coordination and collaboration within the team. A significant part of the developer’s day is spent on team activities – meeting to coordinate tasks, mentoring interns, helping out teammates. Many of these are unscheduled, and certainly not documented the way coding tasks are, meaning they often fall out of the traditional view of “productive time” even if they are integral to the project. It’s time that we take a new look at software productivity and view it from the lens of the team as a whole.

Questions

Our team of researchers set out to investigate two outstanding questions:

• What happens when we ask developers to think about their team’s productivity? What is the relationship between how a developer views their own productivity and how they view their team’s productivity?
• How is this affected by the developer’s activities that day, such as meetings, interactions with the team, and work on collaborative tasks?

Method

To answer these questions, we invited 25 software developers from four companies across the US and Europe to participate in a 3-month field study. We asked them questions about their productivity and activities on a short-term (bi-hourly), medium-term (daily), and long-term (monthly) scale. Every two hours, the participant would see a pop-up on their smartwatch, asking them to rate their own productivity, their team’s productivity, their stress level, and what activity they were engaged in. These frequent self-repots were then presented back to the participant as a graph in the end-of-day survey, allowing them to reflect about the day with a set of more detailed questions (why they rated their own and their team’s productivity the way they did, how they interacted with the team that day, etc.). Each month, we conducted interviews to dive deeper into these questions to see how developers understand their own progress and their team’s overall.

Results

Among other curious findings, we found that:

• Software teams are fluid constructs. Depending on the company, teams are often nested, consisting of smaller subteams (e.g. a features and bug team). The boundaries are often soft, with some developers participating in multiple teams. Finally, these teams change frequently to match the needs of the project. This fluidity is often not reflected in organizational charts, even though it can be important for understanding the workings of the software team.
• Team awareness is limited, and made challenging by this fluidity. This was especially the case for developers working remotely.
• Individual productivity was closely linked to team productivity. In fact, individual productivity was the biggest predictor of team productivity – even more than the type of work done, amount of team interactions, unplanned work, or time spent in meetings.
• Managers have a more holistic view of productivity. Whereas developers often viewed their productivity as a ratio of DONE’s vs TODO’s, their managers spoke about productivity from a more well-rounded perspective: creating value, making impact, supporting the team, moving the project forward.

Conclusion

We’ve got more work to do.

Both in software research and industry, we need to view software productivity more holistically. Software development is more than a lineup of individual developers cranking out code. These complex projects involve teamwork, collaboration, and lending your time to others. The importance of this should be reflected in progress measuring tools so that developers can start rethinking productivity. Instead of thinking “I got none of my assigned tasks done today”, the developer can feel accomplished for helping teammates with pressing tasks, furthering the project as a whole. It seems that software leaders already have this mindset, but it needs to be communicated to the developers and be reflected in project management tools.

Because the magic is not only in the 0’s and 1’s, but in the whole software creation process.