Resumption strategies for interrupted programming tasks

Parnin, Chris; Rugaber, Spencer

doi:10.1007/s11219-010-9104-9

Cited by 79 publications

(72 citation statements)

References 48 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…For example, by observing software developers and other information workers at work, Mark et al found that 57% of all tasks are interrupted and are thus often fragmented into small work sessions [29] and Chong and Siino found that most interruptions-many of them were also self-initiated-lasted around 2 to 3 minutes [26]. While many of these interruptions are necessary, they can lead to a higher error rate, slow task resumption and an overall lower work performance [9], [30], [31], [32]. Parnin and Rugaber found, for instance, that only one out of ten interrupted programming tasks is being continued within a minute after the interruption [9].…”

Section: Work Fragmentationmentioning

confidence: 99%

“…While many of these interruptions are necessary, they can lead to a higher error rate, slow task resumption and an overall lower work performance [9], [30], [31], [32]. Parnin and Rugaber found, for instance, that only one out of ten interrupted programming tasks is being continued within a minute after the interruption [9].…”

Section: Work Fragmentationmentioning

confidence: 99%

“…Researchers have investigated work practices and work fragmentation in detail from various perspectives, specifically the effect of interruptions on fragmentation (e.g., [6], [7], [8], [9]) and how developers organize their work in terms of tasks and working spheres (e.g., [5], [10]). Using both a diary and an observational study format to understand software developer work practices, Perry and colleagues gained several insights, including that most time was spent coding, and that there was a substantial amount of unplanned interaction with colleagues [2].…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

The Work Life of Developers: Activities, Switches and Perceived Productivity

Meyer

Barton

Murphy

et al. 2017

IIEEE Trans. Software Eng.

129

View full text Add to dashboard Cite

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. Abstract-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.

show abstract

Section: Work Fragmentationmentioning

confidence: 99%

Section: Work Fragmentationmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

The Work Life of Developers: Activities, Switches and Perceived Productivity

Meyer

Barton

Murphy

et al. 2017

IIEEE Trans. Software Eng.

129

View full text Add to dashboard Cite

show abstract

“…After an interruption, people have to scan and evaluate all new information that they have encountered; several short interruptions have a greater effect than one long interruption . Parnin and Rugaber (2011) analyzed 10 000 programming sessions and found that developers returning to a task after an interruption, such as a meeting, needed 15 minutes or more to collect their thoughts and make the first edit for most tasks (57%).…”

Section: Meetings In Generalmentioning

confidence: 99%

The daily stand-up meeting: A grounded theory study

Stray

Sjøberg

Dybå

2016

Journal of Systems and Software

100

View full text Add to dashboard Cite

Context: The daily stand-up meeting is one of the most used agile practices but has rarely been the subject of empirical research. Aim: The present study aims to identify how daily stand-up meetings are conducted and what the attitudes towards them are. Method: A grounded theory study of the daily stand-up meeting was conducted with twelve software teams in three companies in Malaysia, Norway, Poland and the United Kingdom. We interviewed 60 people, observed 79 daily stand-up meetings and collected supplementary data. Results: The factors that contributed the most to a positive attitude towards the daily stand-up meeting were information sharing with the team and the opportunity to discuss and solve problems. The factors that contributed the most to a negative attitude were status reporting to the manager and spending too much time; both the frequency and duration of the meeting were perceived to be too much. Based on our results, we developed a grounded theory of daily stand-up meetings and proposed evidencebased guidelines on how to organize them. Conclusion: Organizations should be aware of the factors that may affect attitude towards daily stand-up meetings and should consider our proposed guidelines to improve the way the meetings are conducted.

show abstract

“…Previous work has shown that interruptions are one of the biggest impediments to productive work, distracting developers from their main task and resuming it takes on average about 15 minutes [13,18]. My goal is to reduce interruptions at inopportune, costly moments by provisioning actionable insights to an individual developer that increase the awareness about co-workers' current focus at work.…”

Section: For Co-workersmentioning

confidence: 99%

Fostering software developers' productivity at work through self-monitoring and goal-setting

Meyer

2018

Proceedings of the 40th International Conference on Software Engineering: Companion Proceeedings

View full text Add to dashboard Cite

Software development organizations strive to enhance the productivity of their developers. While research has looked into various ways for improving developer productivity, little is known about the activities they pursue at work, how these activities influence the fragmentation of work, and how these insights could be leveraged to foster productivity at work. In my PhD thesis, I address software developer productivity by taking a mixed-method approach to investigate developers' perceptions of productivity in the field and to examine the individual differences of each developer's work. My goal is to increase developers' awareness about their own work habits and productivity, and to encourage productive behavior changes at work through the provision of two persuasive technologies, self-monitoring and goalsetting. DOI ABSTRACTSoftware development organizations strive to enhance the productivity of their developers. While research has looked into various ways for improving developer productivity, little is known about the activities they pursue at work, how these activities influence the fragmentation of work, and how these insights could be leveraged to foster productivity at work. In my PhD thesis, I address software developer productivity by taking a mixed-method approach to investigate developers' perceptions of productivity in the field and to examine the individual differences of each developer's work. My goal is to increase developers' awareness about their own work habits and productivity, and to encourage productive behavior changes at work through the provision of two persuasive technologies, selfmonitoring and goal-setting. CCS CONCEPTS• Human-centered computing → User studies; PROBLEM STATEMENTThere is a common refrain that repeats itself in similar forms every couple of years: our inability to produce enough software to satisfy the needs of the world. For example, in 1968, attendees at the first NATO software engineering conference coined the term software crisis [17] and in 2011, Andreessen wrote about software eating the world, expressing that the need for software keeps outstripping our ability to produce it [1]. There are a couple of ways of addressing the gap between software demand and supply. We could try to reduce the demand, which seems unlikely to succeed. Or, we could try to increase the supply, namely our ability to produce software. In this PhD thesis, I focus on one way to increase the supply of software: the improvement of software developers' productivity. A substantial amount of work researching developer productivity has been undertaken over the past four decades. The majority of this research introduces particular definitions of productivity, such as measuring productivity based on the number of lines of source code modified per hour [8] or the resolution time for modification requests [16]. Another body of research considers organizational factors associated with productivity, such as the effect of the workplace setting on productivity [7], and soft factors, such as inte...

show abstract

Resumption strategies for interrupted programming tasks

Cited by 79 publications

References 48 publications

The Work Life of Developers: Activities, Switches and Perceived Productivity

The Work Life of Developers: Activities, Switches and Perceived Productivity

The daily stand-up meeting: A grounded theory study

Fostering software developers' productivity at work through self-monitoring and goal-setting

Contact Info

Product

Resources

About