productivity

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.