Contributions published at Human Aspects of Software Engineering (Thomas Fritz)

Knowledge workers have multiple competing responsibilities, ranging from answering emails, attending meetings to performing highly demanding tasks. To be successful at work and get things done, workers have to continuously plan ahead or determine what's best to work on right now. Planning is vital for completing projects and accomplishing longer tasks, since keeping a high-level picture in mind while simultaneously concentrating on the solution is challenging. Productivity of the knowledge worker depends on many different factors, ranging from environmental like interruptions to personal like sleep duration and quality. However, none of the existing approaches for automated task scheduling takes personal productivity factors into account. To alleviate the planning effort and help knowledge workers in allocating their personal resources of time and energy to achieve effective task execution, we have devised a concept of constraint-based workday planning and implemented as a prototype, DayO. Taking the list of tasks created by the user, DayO generates schedule suggestions based on task characteristics, appointments scheduled for today and productivity factors. The evaluation of DayO with knowledge workers has shown that suggestions of workday plan display high accuracy and that concept presented in this thesis can be used for task scheduling at work.

null

Due to the high number and cost of interruptions at work, several approaches have been suggested to reduce this cost for knowledge workers. These approaches predominantly focus either on a manual and physical indicator, such as headphones or a closed office door, or on the automatic measure of a worker's interruptibilty in combination with a computer-based indicator. Little is known about the combination of a physical indicator with an automatic interruptibility measure and its long-term impact in the workplace. In our research, we developed the FlowLight, that combines a physical traffic-light like LED with an automatic interruptibility measure based on computer interaction data. In a large-scale and long-term field study with 449 participants from 12 countries, we found, amongst other results, that the FlowLight reduced the interruptions of participants by 46%, increased their awareness on the potential disruptiveness of interruptions and most participants never stopped using it.

Many software development organizations strive to enhance the productivity of their developers. All too often, efforts aimed at improving developer productivity are undertaken without knowledge about how developers spend their time at work and how it influences their own perception of productivity. To fill in this gap, we deployed a monitoring application at 20 computers of professional software developers from four companies for an average of 11 full workdays in situ. Corroborating earlier findings, we found that developers spend their time on a wide variety of activities and switch regularly between them, resulting in highly fragmented work. Our findings extend beyond existing research in that we correlate developers’ work habits with perceived productivity and also show productivity is a personal matter. Although productivity is personal, developers can be roughly grouped into morning, low-at-lunch and afternoon people. A stepwise linear regression per participant revealed that more user input is most often associated with a positive, and emails, planned meetings and work unrelated websites with a negative perception of productivity. We discuss opportunities of our findings, the potential to predict high and low productivity and suggest design approaches to create better tool support for planning developers’ workdays and improving their personal productivity.

The more we know about software developers’ detailed navigation behavior for change tasks, the better we are able to provide effective tool support. Currently, most empirical studies on developers performing change tasks are, however, limited to very small code snippets or limited by the granularity and detail of the data collected on developer’s navigation behavior. In our research, we extend this work by combining user interaction monitoring to gather interaction context – the code elements a developer selects and edits – with eye-tracking to gather more detailed and fine-granular gaze context-code elements a developer looked at. In a study with 12 professional and 10 student developers we gathered interaction and gaze contexts from participants working on three change tasks of an open source system. Based on an analysis of the data we found, amongst other results, that gaze context captures different aspects than interaction context and that developers only read small portions of code elements. We further explore the potential of the more detailed and fine-granular data by examining the use of the captured change task context to predict perceived task difficulty and to provide better and more fine-grained navigation recommendations. We discuss our findings and their implications for better tool support.

null

Nine rising stars in software engineering describe how software engineering research will evolve, highlighting emerging opportunities and groundbreaking solutions. They predict the rise of end-user programming, the monitoring of developers through neuroimaging and biometrics sensors, analysis of data from unstructured documents, the mining of mobile marketplaces, and changes to how we create and release software.

Measuring productivity of individual developers is challenging. In some domains, such as car manufacturing, specific outcome measures over time, such as the number of cars produced in a day, can work well to measure and incentivize productivity. However, the less clearly defined and more flexible process of software development makes it difficult, if not impossible, to define such measures. In particular, there is no single and simple best metric that can be used for all software developers and more individual combinations of measures are wanted and needed that also take into account the process and not just the final outcome. In this chapter, we will discuss some of the challenges and previous insights on the measuring of individual developer productivity.

Past studies show that developers who navigate code in a structural manner complete tasks faster and more correctly than those whose behavior is more opportunistic. The goal of this work is to move professional developers towards more effective program comprehension and maintenance habits by providing an approach that fosters structural code navigation. To this end, we created a Visual Studio plugin called Prodet that integrates an always-on navigable visualization of the most contextually relevant portions of the call graph. We evaluated the effectiveness of our approach by deploying it in a six week field study with professional software developers. The study results show a statistically significant increase in developers’ use of structural navigation after installing Prodet. The results also show that developers continuously used the filtered and navigable call graph over the three week period in which it was deployed in production. These results indicate the maturity and value of our approach to increase developers’ effectiveness in a practical and professional environment.

Integrated development environments such as Eclipse and Visual Studio provide tools and capabilities to perform tasks such as navigating among classes and methods, continuous compilation, code refactoring, automated testing, and integrated debugging, all designed to increase productivity. Instrumenting the integrated development environment to collect usage data provides a more fine-grained understanding of developers' work than was previously possible. Usage data supports analysis of how developers spend their time, what activities might benefit from greater tool support, where developers have difficulty comprehending code, and whether they are following specific practices such as test-driven development. With usage data, we expect to uncover more nuggets of how developers create mental models, how they investigate code, how they perform mini trial-and-error experiments, and what might drive productivity improvements for everyone.

The better the software development community becomes at creating software, the more software the world seems to demand. Although there is a large body of research about measuring and investigating productivity from an organizational point of view, there is a paucity of research about how software developers, those at the front-line of software construction, think about, assess and try to improve their productivity. To investigate software developers' perceptions of software development productivity, we conducted two studies: a survey with 379 professional software developers to help elicit themes and an observational study with 11 professional software developers to investigate emergent themes in more detail. In both studies, we found that developers perceive their days as productive when they complete many or big tasks without significant interruptions or context switches. Yet, the observational data we collected shows our participants performed significant task and activity switching while still feeling productive. We analyze such apparent contradictions in our findings and use the analysis to propose ways to better support software developers in a retrospection and improvement of their productivity through the development of new tools and the sharing of best practices.

The aim of this thesis has been to develop a visualization application that supports the analysis of psycho-physiological data recorded from software developers working on code comprehension tasks. Since psycho-physiological (also known as biometric) measurements, such as electrodermal activity (EDA), or electroencephalography (EEG), can be used as indicators for cognitive states, these data are used to detect the difficulties a developer might have experienced during source code comprehension activities. Using three different visualization approaches, a dataset consisting of EEG, EDA and eye-tracking data was investigated with a special focus on the identification of various kinds of patterns (e.g. code reading patterns or time-related biometric patterns). Based on the results of visual inspection (enabled by the visualizations developed for this purpose), significance tests were conducted to verify the findings. The analysis has confirmed eye movement patterns that had been described in previous research. New insights are made regarding time-related patterns. Metric correlations within task data were found, like the accumulation of eyeblinks with concomitant low values for mental focus (Attention eSense™ values). Additionally, metric differences in task pairs of inherently easier/harder tasks were analyzed and interpreted. For example, it was found that the use of mnemonic variable names instead of generic variable names result in a significant lower number of occurrences of the retrace declaration pattern. Learning how software developers read source code and how they emotionally and physiologically react on reading code comprehension tasks could help to locate problematic code segments. Findings in this research field can be used to develop novel programming support tools that make use of psycho-physiological sensors. Depending on programming difficulties detected on the fly (e.g. by identification of biometric patterns), appropriate interventions could be suggested by a rule engine.

The better the software development community becomes at creating software, the more software the world seems to demand. One way to address the gap between software demand and supply is to try to increase the supply, by optimizing the productivity of software developers. Although there is a large body of research about measuring and investigating productivity from an organizational point of view, there is a paucity of research about how software developers, those at the front-line of software construction, think about, assess, and try to improve their productivity. To investigate software developers' perceptions of software development productivity, we conducted two studies: a survey with 379 professional software developers to help elicit themes and an observational study with 11 professional software developers to investigate emergent themes in more detail. In the survey we found that software developers perceive their days as productive when they complete many or big tasks, without significant interruptions or context switches. Yet, the observational data we collected shows our participants performed significant task and activity switching, while still feeling productive. We analyze such apparent contradictions in our findings and use the analysis to propose ways to better support software developers in a retrospection and improvement of their productivity through the development of new tools and the sharing of best practices. Based on the finding that there might not be a single and/or simple measurement for a software developer's productivity, we discuss a new idea to provide a software developer with a meaningful retrospective analysis of his workday and workweek and its possible impact on a developer's productivity.