Skip to main content
Disciplines
Automotive Business IT + Informatics Construction + Real Estate Electrical Engineering + Electronics Energy + Sustainability Insurance + Risk Finance + Banking Management + Leadership Marketing + Sales Mechanical Engineering + Materials
Events
DE
EN
Books
Journals
Topic Page
Marketing
Start single access now
Access for companies
EXTENDED SEARCH
Log in
Top

Open Access 2019 | Open Access | Book

Cover of the book

Rethinking Productivity in Software Engineering

Editors: Caitlin Sadowski, Thomas Zimmermann

Publisher: Apress

Part of: Springer Professional "Wirtschaft+Technik" , Springer Professional "Technik" , Springer Professional "Wirtschaft"

Table of Contents
insite
SEARCH

About this book

Get the most out of this foundational reference and improve the productivity of your software teams. This open access book collects the wisdom of the 2017 "Dagstuhl" seminar on productivity in software engineering, a meeting of community leaders, who came together with the goal of rethinking traditional definitions and measures of productivity.

The results of their work, Rethinking Productivity in Software Engineering, includes chapters 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.
Readers in many fields and industries will benefit from their collected work. Developers wanting to improve their personal productivity, will learn effective strategies for overcoming common issues that interfere with progress. Organizations thinking about building internal programs for measuring productivity of programmers and teams will learn best practices from industry and researchers in measuring productivity. And researchers can leverage the conceptual frameworks and rich body of literature in the book to effectively pursue new research directions.
What You'll LearnReview the definitions and dimensions of software productivity
See how time management is having the opposite of the intended effect
Develop valuable dashboards
Understand the impact of sensors on productivity
Avoid software development waste
Work with human-centered methods to measure productivity
Look at the intersection of neuroscience and productivity
Manage interruptions and context-switching
Who Book Is For
Industry developers and those responsible for seminar-style courses that include a segment on software developer productivity. Chapters are written for a generalist audience, without excessive use of technical terminology.

Table of Contents

Frontmatter
PDF

Measuring Productivity: No Silver Bullet

Frontmatter

Open Access

Chapter 1. The Mythical 10x Programmer
Abstract
Are some programmers indeed ten times more productive than others, as some people claim? To a shocking degree, the answer depends on what exactly the question is intended to mean. In this chapter, we will work our way towards this insight by way of a fictious dialog that is based on actual programming research data.
Lutz Prechelt
PDF View full text

Open Access

Chapter 2. No Single Metric Captures Productivity
Abstract
The urge to measure the productivity of developers is not new. Since it is often the case at organizations that more code needs to be written, many attempts have been made to measure productivity based on lines of code (LOC). For example, in early 1982, the engineering management of developers working on software for the Apple Lisa computer decided to start tracking LOC added by each developer. One week, the main user interface designer, Bill Atkinson, optimized Quickdraw’s region calculation machinery and contributed -2000 LOC. The management stopped asking for his LOC.
Although measuring engineer productivity by LOC is clearly fraught, anecdotes like this abound on the internet. Organizations have continued to search for better easy ways to measure developer productivity. We argue that there is no metric that adequately captures the full space of developer productivity, and that attempting to find one is counter-productive. Instead, we encourage the design of a set of metrics tailored for answering a specific goal.
Ciera Jaspan, Caitlin Sadowski
PDF View full text

Open Access

Chapter 3. Why We Should Not Measure Productivity
Abstract
Software moves faster every year. Markets shift rapidly, releases are ever more frequent, and languages, APIs, and platforms evolve at a relentless pace. And so interest in productivity, both by developers who want to keep up with these changes, but also by managers and organizations who need to compete, appears entirely rational. Moreover, improving software faster holds even greater promise to the rest of humanity: getting more work done with less effort means may mean an increased quality of life for everyone.
In pursuit of productivity, however, there can be unintended consequences from trying to measure it. For instance: Measuring productivity can warp incentives, especially if not measured well; or Sloppy inferences from measurements could result in *worse* management decisions, rather than better ones. Are these bad enough that we shouldn’t even try to measure it? To find out, let’s do a thought experiment.
Amy J. Ko
PDF View full text

Introduction to Productivity

Frontmatter

Open Access

Chapter 4. Defining Productivity in Software Engineering
Abstract
Successful software systems are subject to perpetual change as they need to be continuously improved and adapted to continuously changing requirements. Software evolution is the term used in software engineering to refer to this process of developing software initially, then repeatedly updating it. It is an essential goal to minimize the cost and to maximize the benefits of software evolution. In addition to financial savings, for many organizations, the time needed to implement software changes largely determines their ability to adapt their business processes to changing market situations and to implement innovative products and services. With the present yet increasing dependency on large scale software systems, the ability to develop and change existing software in a timely and economical manner is essential for numerous enterprises and organizations in most domains.
We commonly call this *productivity* which across disciplines and domains refers to the ratio between output and input. The input side - the cost spent - is relatively easy to measure in software development. The challenge lies in finding a reasonable way to define output as it involves software quantity and quality.
Stefan Wagner, Florian Deissenboeck
PDF View full text

Open Access

Chapter 5. A Software Development Productivity Framework
Abstract
Productivity is a challenging concept to define, describe and to measure for any kind of knowledge work that involves non-routine creative tasks. Software development is a prime example of knowledge work, as it too often involves poorly defined tasks relying on extensive collaborative and creative endeavours. As in other areas of knowledge work, defining productivity in software development has been a challenge facing both researchers and practitioners that may wish to understand and improve it by introducing new tools or processes.
In this chapter, we present a framework for conceptualizing productivity in software development according to three main dimensions that we propose are essential for understanding productivity. In order to help clarify productivity goals, we also propose a set of *lenses* that provide different perspectives for considering productivity along these three dimensions. We contend that any picture of productivity would be incomplete if the three dimensions and various lenses are not considered.
Caitlin Sadowski, Margaret-Anne Storey, Robert Feldt
PDF View full text

Open Access

Chapter 6. Individual, Team, Organization, and Market: Four Lenses of Productivity
Abstract
When we think about productivity in software development, it’s reasonable to start with a basic concept of work per unit of effort. The more work a developer accomplishes with their efforts, the better.
But when researchers have investigated how developers think about productivity, some surprising nuance surfaces about what software engineering “work” actually is and at what level this work should be considered. In particular, there are four lenses through which one can reason about productivity and each of these has different implications for what actions one might take to increase productivity in a company.
Amy J. Ko
PDF View full text

Open Access

Chapter 7. Software Productivity Through the Lens of Knowledge Work
Abstract
Other fields have studied productivity more broadly than the software engineering field. Such work lends a perspective that can contribute to a solid foundation to what we know about software developer productivity. In this chapter, we provide an overview of related work about perhaps the most relevant allied field outside of software engineering, namely, the productivity of knowledge workers.
Emerson Murphy-Hill, Stefan Wagner
PDF View full text

The Context of Productivity

Frontmatter

Open Access

Chapter 8. Factors That Influence Productivity: A Checklist
Abstract
In all areas of professional work, there is are a lot of different factors that influence productivity. Especially in knowledge work, where we do not have easily and clearly measurable work products, it is difficult to capture these factors. Software development is a type of knowledge work that comes with even more specific difficulties, as software developers deal nowadays with incredibly large and complex systems.
We provide a list of factors that empirically have been shown to impact productivity as checklist that a developer or software manager can use to improve productivity. We will discuss technical factors related to the product, the process and the development environment and soft factors related to the corporate culture, the team culture, individual skills and experiences, the work environment and the individual project.
Stefan Wagner, Emerson Murphy-Hill
PDF View full text

Open Access

Chapter 9. How Do Interruptions Affect Productivity?
Abstract
Work is frequently interrupted. What is known about how interruptions affect productivity? This important question has been studied using a variety of research methods, from controlled experiments designed to learn about the effect of interruptions on task performance, to analytical cognitive models that explain what makes an interruption disruptive, to in-situ observational studies that document the kinds of interruptions people experience in their actual workplaces. In this chapter, we review research on interruptions that has used these three research methods. We review what the methods entail, and what insights it has given on how interruptions affect productivity.
Duncan P. Brumby, Christian P. Janssen, Gloria Mark
PDF View full text

Open Access

Chapter 10. Happiness and the Productivity of Software Engineers
Abstract
Software companies and startups often follow the idea of flourishing happiness among developers. Perks, playground rooms, free breakfast, remote office options, sports facilities near the companies, company retreats, you name it. The rationale is that happy developers should be more productive and also retained.
But is it the case that happy software engineers are more productive? Moreover, are perks the way to go to make developers happy? Are developers happy at all? What are the consequences of unhappiness among software engineers?
These questions are important to ask both from the perspective of productivity and from the perspective of sustainable software development and well-being in the workplace. Managers, team leaders, as well as team members should be interested in these concerns.
This chapter provides an overview of our studies on the happiness of software developers. You will learn why it is important to make software developers happy, how happy they really are, what makes them unhappy, and what is expected regarding happiness and productivity while developing software.
Daniel Graziotin, Fabian Fagerholm
PDF View full text

Open Access

Chapter 11. Dark Agile: Perceiving People As Assets, Not Humans
Abstract
The Agile principles for software engineering were developed as a reaction against structuring software engineering processes in strict stepwise and sequential ways. The agile understanding of software engineering is that the fundamental nature of software means that we cannot pre-determined scope, goal, and objectives upfront. Instead goals, scope, and objectives are transformed throughout the process where the programming code gets created. The agile principles are based upon the main idea of providing the power over software engineering to the people - the software team.
When we, in computer science departments at Danish universities, teach computer science students about software engineering - we talk about the benefits of agile development, as well as on the problem with the waterfall model. We explain how the waterfall model does not take into account the iterative and creative process of developing software. Further, if you visit any kind of Danish IT company and talk to the developers and ask them about methods - they will tell you how the waterfall model does not work, and how agile methodologies provides better quality within the appropriate time frame. Agile is seen as a positive perspective on software engineering in Denmark.
However, the story about agile is quite different when we change perspective from Scandinavia and turn to India.
Pernille Bjørn
PDF View full text

Measuring Productivity in Practice

Frontmatter

Open Access

Chapter 12. Developers’ Diverging Perceptions of Productivity
Abstract
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.
André N. Meyer, Gail C. Murphy, Thomas Fritz, Thomas Zimmermann
PDF View full text

Open Access

Chapter 13. Human-Centered Methods to Boost Productivity
Abstract
Since programming is a human activity, we can look to fields which have already developed methods for better understanding the details of human interactions with technologies. In particular, the field of human-computer interaction (HCI) has dozens, if not hundreds, of methods that have been validated for answering a wide range of questions about human behaviors. (And many of these methods, in turn, have been adapted from methods used in psychology, ethnography, sociology, etc.) For example, in our research, we have documented the use of at least 10 different human-centered methods across all the phases of software development, almost all of which have impacts on programmer productivity.
Brad A. Myers, Amy J. Ko, Thomas D. LaToza, YoungSeok Yoon
PDF View full text

Open Access

Chapter 14. Using Biometric Sensors to Measure Productivity
Abstract
If we want to be productive, it would be great if we could track productivity in some way, such that it is possible to determine what factors help and hinder productivity. Biometric sensors may be helpful for such productivity tracking. But what does being productive mean?
Productivity requires sometimes singular focus, and sometimes distraction. What is crucial is monitoring to ensure that attention is being paid to the most relevant goals, and that the degree of attentional focus is in line with those goals. The attentional focus should neither be too narrow, nor too wide, and should be directed to the task that is most important at that moment.
In this chapter I will first discuss biometric sensors on the basis of eyetracking and electroencephalography (EEG) that simply track attention, and then preview some new potential sensors that track the broader definition of productivity that depends on focusing on the most relevant goals and not being sidetracked by thoughts that pull one away.
Marieke van Vugt
PDF View full text

Open Access

Chapter 15. How Team Awareness Influences Perceptions of Developer Productivity
Abstract
While tools which help developers make sense of everything that goes on in a software project are necessary to enable developer awareness, these tools currently favour quantitative information over qualitative information. To accuractly represent what goes on in a software project, awareness tools need to focus on summarizing instead of measuring information and be careful when presenting numbers which could be used as an unintended proxy for productivity measures. We argue for the use of natural language and text processing techniques to automatically summarize information from a software project in textual form. Based on the findings of our study, we suggest that such tools should categorize the events in a software project according to whether they are expected or unexpected, and use natural language processing to provide meaningful summaries rather than numbers and graphs which are likely to be misinterpreted as productivity measures.
Christoph Treude, Fernando Figueira Filho
PDF View full text

Open Access

Chapter 16. Software Engineering Dashboards: Types, Risks, and Future
Abstract
The large number of artifacts created or modified in a software project and the flood of information exchanged in the process of creating a software product call for tools that aggregate this data to communicate higher-level insights to all stakeholders involved. In many projects -- in software engineering as well as in other domains -- dashboards are used to communicate information that may bring insights on the productivity of project activities and other insights. The goal of dashboards is to transform the raw data contained in an organization’s repositories into consumable information. In software engineering, dashboards are used to provide information related to questions such as “is this project on schedule?”, “what are the current bottlenecks?”, and “what is the progress of other teams?”. In this chapter, we review the different types of dashboards that are commonly used in software engineering and the risks that are associated with their use.
Margaret-Anne Storey, Christoph Treude
PDF View full text

Open Access

Chapter 17. The COSMIC Method for Measuring the Work-Output Component of Productivity
Abstract
The productivity of a software activity may be defined generally as 'work-output/work-input', where work-input is the effort needed to produce the work-output. In this chapter we describe the ISO standard COSMIC method which was designed to measure a size of the work-output from a software process. Sizes had to be useful for productivity measurement and for effort estimation, for most types of software.
Charles Symons
PDF View full text

Open Access

Chapter 18. Benchmarking: Comparing Apples to Apples
Abstract
For almost every organization, software development is becoming more and more important. The ability to develop and to release new functionality to the users and customers as fast as possible, is often one of the main drivers to gain a competitive edge. However, in the software industry, there is a huge difference in productivity between the best and the worst performers. Productivity can be a crucial element for many organizations (as well as cost efficiency, speed and quality) to bring their competitiveness in line with their most relevant competitors.
Benchmarking is the process of comparing your organization’s processes against industry leaders or industry best practices (outward focus) or comparing your own teams (inward focus). Benchmarking gives insight into best practices, with the aim to understand if and how one should improve to stay or become successful. Software development benchmarking can be done on any scale that is comparable: a sprint, a release, a project or a portfolio.
Frank Vogelezang, Harold van Heeringen
PDF View full text

Best Practices for Productivity

Frontmatter

Open Access

Chapter 19. Removing Software Development Waste to Improve Productivity
Abstract
One way to improve productivity is to reduce waste: objects, properties, conditions, activities, or processes that consume resources without benefiting stakeholders. However, reducing waste can be very challenging. People quickly acclimate to wasteful practices and waste is often hidden by bureaucracy, multitasking, poor prioritization, and invisible cognitive processes. To better understand software development waste, we conducted an in-depth study of waste at Pivotal Software, a large American software development organization, known for using and evolving Extreme Programming. This chapter describes the different kinds of waste we discovered and recommends a variety of strategies for waste removal.
Todd Sedano, Paul Ralph, Cécile Péraire
PDF View full text

Open Access

Chapter 20. Organizational Maturity: The Elephant Affecting Productivity
Abstract
The maturity of an organization’s software development environment impacts the productivity of its developers and their teams. Consequently, organizational attributes should be measured and factored into estimates of cost, schedule, and quality. This chapter presents an evolutionary model of organizational maturity, how the model can guide productivity and quality improvements, and how its practices can be adapted to evolving development methods.
Bill Curtis
PDF View full text

Open Access

Chapter 21. Does Pair Programming Pay Off?
Abstract
Pair programming means two developers working together closely on the same software development task on a single computer. It is not obvious whether this is an efficient practice: While a pair can often work faster and better, it also occupies two team members. We have studied this for several years by analyzing recordings of dozens of actual industrial pair programming sessions. Our observations suggest that pair programming that pays off will typically (need to) exhibit high process fluency. They also suggest that it is going to pay off when the pair members’ knowledge is highly complementary.
Franz Zieris, Lutz Prechelt
PDF View full text

Open Access

Chapter 22. Fitbit for Developers: Self-Monitoring at Work
Abstract
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.
André N. Meyer, Thomas Fritz, Thomas Zimmermann
PDF View full text

Open Access

Chapter 23. Reducing Interruptions at Work with FlowLight
Abstract
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.
Manuela Züger, André N. Meyer, Thomas Fritz, David Shepherd
PDF View full text

Open Access

Chapter 24. Enabling Productive Software Development by Improving Information Flow
Abstract
At its core, software development is an information-intensive knowledge generation and consumption activity. We are interested in how software tools can enable the productive development of software. Our hypothesis has been that software development productivity can be increased by improving the access and flow of information between the humans and tools involved in creating software systems. In this chapter, we review an evolution of technologies we have introduced based on this hypothesis. These technologies are in use by large software development organization and have been shown to improve software developer productivity. The description of these technologies also highlights how productivity can be considered at the individual, team and organizational level.
Gail C. Murphy, Mik Kersten, Robert Elves, Nicole Bryan
PDF View full text

Open Access

Chapter 25. Mindfulness as a Potential Tool for Productivity
Abstract
No day passes without seeing mindfulness mentioned in popular blogs as the solution for productivity. Many large companies offer mindfulness classes. Why would mindfulness be useful for productivity? Before discussing that question, it is important to first define mindfulness. Traditionally it has been defined by the originator of the mindfulness movement Jon Kabat-Zinn as “paying attention in a particular way, in the present moment, non-judgmentally”.
Mindfulness is widely used in hospitals to reduce stress and support healing. It has also been touted as a solution for employees to allow them to maintain well-being in a very stressful environment. The idea is that you learn to relax by bringing your attention to your breath, and not taking your thoughts so seriously. Some preliminary evidence for mindfulness’ effect on stress reduction showed that employees of a biotech firm, when given a mindfulness intervention, felt less stressed and showed an improved immune response.
Marieke van Vugt
PDF View full text
Backmatter
PDF
Metadata
Title
Rethinking Productivity in Software Engineering
Editors
Caitlin Sadowski
Thomas Zimmermann
Copyright Year
2019
Publisher
Apress
Electronic ISBN
978-1-4842-4221-6
Print ISBN
978-1-4842-4220-9
DOI
https://doi.org/10.1007/978-1-4842-4221-6

Premium Partner

    Image Credits