I am proud to have been given the chance to author three chapters in our new productivity book, which is the result from a thought-provoking and discussion-intensive Dagstuhl Seminar in 2017. It was edited by Caitlin Sadowski and Thomas Zimmermann, and is available for free (OpenAccess). In the book, software engineering researchers review and discuss productivity, by covering definitions and core concepts related to productivity, guidelines for measuring productivity in specific contexts, best practices and pitfalls, and theories and open questions on productivity. You’ll benefit from the many short chapters, each offering a focused discussion on one aspect of productivity in software engineering.
Developers’ Diverging Perceptions of Productivity
To overcome the ever-growing demand for software, software development organizations strive to enhance the productivity of their developers. But what does productivity mean in the context of software development? A substantial amount of work on developer productivity has been undertaken over the past four decades. The majority of this work considered productivity from a top-down perspective (the manager view) in terms of the artifacts and code created per unit of time. Common examples of such productivity measures are the lines of source code modified per hour, the resolution time for modification requests, or function points created per month. These productivity measures focus on a single, output-oriented factor for quantifying productivity, and do not take into account developers’ individual work roles, practices and other factors that might affect their productivity, such as work fragmentation, the tools used, or the work/office environment. In our research, we investigated how productivity could be quantified from the bottom-up, following a mixed-methods approach that involved more than 800 software developers. By investigating developers’ individual productivity, it is possible to better understand the individual work habits and patterns, how they relate to the productivity perceptions and also which factors are most relevant for a developer’s productivity.
Fitbit for Developers: Self-Monitoring at Work
Recently, we have seen an explosion in the number of devices and apps that we can use to track various aspects of our lives, such as the steps we walk, the quality of our sleep, or the calories we consume. People use devices such as the Fitbit activity tracker to increase and maintain their physical activity level by tracking their behavior, setting goals (e.g. 10’000 steps a day) and competing with friends. Many of these approaches have been shown to successfully encourage users to change their behaviors, often motivated through persuasive technologies, such as goal-setting, social encouragement and sharing mechanisms. We explored how we can map the tremendous success of these smart devices to the workplace, with the aim to increase software developers’ self-awareness about productivity through self-monitoring. Yet, little is known about expectations of, the experience with, and the impact of self-monitoring in the workplace. From a mixed-methods approach we inferred design elements for building workplace self-monitoring tools, which we then implemented as a technology probe called WorkAnalytics. We field-tested these design elements during a three-week study with software development professionals. In the field study, we found that self-monitoring paired with experience sampling increases developers’ awareness about work and motivates many to improve their behaviors, and that a wide variety of different metrics is needed to fulfill developers’ expectations. Our work can serve as a starting point for researchers and practitioners to build self-monitoring tools for the workplace.
Reducing Interruptions at Work with FlowLight
Interruptions at the workplace can consume a lot of time and cause frustration, especially if they happen at moments of high focus. To reduce costly interruptions, we developed the FlowLight, a small LED Lamp mounted at a worker’s desk that computes a worker’s availability for interruptions based on computer interaction and indicates it to her coworkers with colors, similar to a traffic light. In a large study with 449 participants, we found that the FlowLight reduced interruptions by 46%. We also observed an increased awareness of the potential harm of interruptions and an increased feeling of productivity. In this chapter, we present our insights from developing and evaluating FlowLight, and reflect on the key factors that contributed to its success.
Comments are closed.