Talk of software development productivity abounds. New languages, like Dart, promise software developers that they don’t have to choose between productivity and performance for the programs they write. New DevOps tools, like ElectricFlow, promise to accelerate everything to improve developer productivity. Perhaps your team’s productivity is not limited by languages or tools, but rather how you organize or track your team’s work, communication, or something completely different.
Do you know what most affects software development productivity in your organization? Probably not, and you are not alone.
Along with my colleagues André Meyer and Thomas Fritz at the University of Zurich, and Thomas Zimmermann at Microsoft Research, we searched for what is known about software development productivity. We found many theories about how productivity might be measured and what organizational factors might affect productivity. We also found many suggestions for how to improve productivity. But we found nothing about how software developers themselves think about productivity and what they perceive affects it. As we believe that improving productivity requires understanding the issues, we set about to fill this gap.
To gain a broad view about what productivity means to software developers and how developers think about assessing their own productivity, we conducted a survey of 379 developers whose average professional experience was 9.2 (± 7.3) years. The survey had 17 questions about productivity: Seven were about perceptions of productivity, seven were about how developers set goals, and three were about how to improve and monitor productivity.
(Related: Getting all hands on deck with agile)
From this survey, we learned about factors that lead a developer to have a productive or unproductive day. Not surprisingly, the two top factors leading to a productive day were when developers complete tasks (53% of respondents) and when they are able to work with few interruptions or distractions (50%). Also not surprising was that developers are productive when they have no meetings (21%). The fourth and fifth most mentioned factors were somewhat more surprising as they indicated the reflective nature of many developers’ work: Developers perceived they were productive when clear goals are set (20%) and they plan their workday (17%).
At a more fine-grained level, we asked developers which activities they perform are productive or not. While developers reported coding as the most productive activity (71%), other activities were more mixed. Most developers (58%) thought meetings were unproductive, particularly when the meeting lacked goals or there were too many attendees. But almost a fifth of the developers (17%) thought meetings with clear decision-making were productive.
Developers were in general satisfied with their productivity on the previous workday and workweek, reporting a median of 4 (satisfied) on a five-point scale. Most developers (78%) assessed their productivity based on tasks completed, although several (27%) mentioned such measures as lines of code, number of commits, number of bugs found or fixed, and e-mails sent.
Surveys provide an overview of how developers perceive productivity, but can’t tell what really happens in a developer’s workday. To further deepen our understanding of developers and their productivity, we observed 11 developers from three companies of varying sizes for four hours each on a single workday. The observer recorded everything the developer did: tasks performed, tools used, time spent using each tool and so on. Across the observation sessions, we collected information about 2,650 events over 44 total hours of work. We then analyzed the data to understand what work occurred, when, and for how long.
In these four-hour sessions, developers worked on two to 10 tasks. Work on tasks was not consecutive; in fact, developers switched frequently between tasks with a mean switch rate of 13.3 (±8.5) times per hour. The average time spent on a task was 6.2 (±3.3) minutes. Despite all these switches, developers mostly (73%) reported the sessions as productive for them. These task switches happened for many reasons, including helping coworkers to make progress or become unblocked, as well as because they themselves were blocked—for instance, waiting for a build to complete.
While performing tasks, developers were involved in many activities. They switched activities very frequently: Forty-seven (±19.8) times per hour, spending an average of 1.6 (±0.8) minutes on each activity before switching. The largest amount of time was spent on coding (32%), followed by testing (12%).
We also analyzed which activities the developers switched between. Coding was most common, followed immediately by testing (28% of cases). However, coding was also often followed by an informal meeting (14%), because someone would ask a question. E-mails were mostly checked during coding (18%) or testing (19%), and developers generally returned to testing (20%), coding (17%) or planning (19%) after the e-mail check.
To perform these activities, developers used a large number of programs: Fourteen (±3.9).
What can one do with this information? Building on the quantified self-movement, we have started to work on dashboards that bring together keyboard activity and activity in software repositories with developer input about when they are productive. With such information, we can help developers reflect on whether they are most productive in the mornings or afternoons, and we can start to build tools that help them protect that time by automatically adding calendar entries to block their time as well as other simple aids. We are also working on methods to assess the impact of task switches that are disruptive to try to help developers organize their workday to stay focused on tasks requiring deep thought or creativity.
There likely is no one magic tool or technique that one can wave to suddenly improve developer productivity. But by understanding what your developers do all day and what activities they find full of friction, you can take steps to keep developers in the flow and producing great software.
