10 research outputs found

    Developers’ Diverging Perceptions of Productivity

    Full text link
    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

    Measuring Human Values in Software Engineering

    Get PDF
    Background: Human values, such as prestige, social justice, and financial success, influence software production decision-making processes. While their subjectivity makes some values difficult to measure, their impact on software motivates our research. Aim: To contribute to the scientific understanding and the empirical investigation of human values in Software Engineering (SE). Approach: Drawing from social psychology, we consider values as mental representations to be investigated on three levels: at a system (L1), personal (L2), and instantiation level (L3). Method: We design and develop a selection of tools for the investigation of values at each level, and focus on the design, development, and use of the Values Q-Sort. Results: From our study with 12 software practitioners, it is possible to extract three values ‘prototypes’ indicative of an emergent typology of values considerations in SE. Conclusions: The Values Q-Sort generates quantitative values prototypes indicating values relations (L1) as well as rich personal narratives (L2) that reflect specific software practices (L3). It thus offers a systematic, empirical approach to capturing values in SE

    "Do this! Do that!, And Nothing will happen":Do specifications lead to securely stored passwords?

    Get PDF
    Does the act of writing a specification (how the code should behave) for a piece of security sensitive code lead to developers producing more secure code? We asked 138 developers to write a snippet of code to store a password: Half of them were asked to write down a specification of how the code should behave before writing the program, the other half were asked to write the code but without being prompted to write a specification first. We find that explicitly prompting developers to write a specification has a small positive effect on the security of password storage approaches implemented. However, developers often fail to store passwords securely, despite claiming to be confident and knowledgeable in their approaches, and despite considering an appropriate range of threats. We find a need for developer-centered usable mechanisms for telling developers how to store passwords: lists of what they must do are not working

    Rethinking Productivity in Software Engineering

    Get PDF
    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 Learn Review 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. ; Collects the wisdom of software engineering thought leaders in a form digestible for any developer Shares hard-won best practices and pitfalls to avoid An up to date look at current practices in software engineering productivit

    Rethinking Productivity in Software Engineering

    Get PDF
    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 Learn Review 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. ; Collects the wisdom of software engineering thought leaders in a form digestible for any developer Shares hard-won best practices and pitfalls to avoid An up to date look at current practices in software engineering productivit

    Characterizing Software Developers by Perceptions of Productivity

    Full text link
    Understanding developer productivity is important to deliver software on time and at reasonable cost. Yet, there are numerous definitions of productivity and, as previous research found, productivity means different things to different developers. In this paper, we analyze the variation in productivity perceptions based on an online survey with 413 professional software developers at Microsoft. Through a cluster analysis, we identify and describe six groups of developers with similar perceptions of productivity: social, lone, focused, balanced, leading, and goal-oriented developers. We argue why personalized recommendations for improving software developers’ work is important and discuss design implications of these clusters for tools to support developers’ productivity

    A influência de fatores na produtividade do desenvolvimento de software de acordo com um modelo de estruturas teóricas

    Get PDF
    This work presents an evidence-based model describing the effects of a set of factors on software development productivity, obtained through an evidence synthesis method in Software Engineering. Thus, the relationships among this set and the software development productivity (observed phenomena) are described as results of combining theoretical structures capable of expressing and dealing with differences between different effects and uncertainties varying according to the types of studies found in the literature. Besides, to evaluate the model found, its findings are confronted with a survey capturing the practitioners’ perception (managers and leaders of software projects in Brazilian organizations). The degree of agreement between research (the model) and practice (the practitioners’ perception) shows that scientific knowledge does not differ considerably from the reality experienced by software projects when both of them refer to the influence of factors on software development productivity. The impression that research and practice on the theme go through different paths persists. According to this work, the reasons for this impression are more related to the use of non-standardized and, perhaps, inappropriate measures used to perceive and monitor the influence of factors as well as to measure the software development productivityEste trabalho apresenta um modelo baseado em evidências que descreve efeitos de alguns fatores na produtividade do desenvolvimento de software, obtidos através de um método de síntese de evidências em Engenharia de Software. Deste modo, as relações entre um conjunto de fatores e a produtividade do desenvolvimento de software (fenômenos observados) são descritas como resultados da combinação de estruturas teóricas capazes de expressar e tratar diferenças entre efeitos e incertezas variadas de acordo com os tipos de estudos primários encontrados na literatura. Além disso, para avaliar o modelo encontrado, seus achados são confrontados com uma pesquisa de opinião realizada para capturar a percepção de profissionais da prática (gestores e líderes de projetos de software em organizações brasileiras). O grau de concordância entre a pesquisa (o modelo) e a prática (a percepção dos profissionais) demonstra que, aparentemente, o conhecimento científico não diverge consideravelmente da realidade vivenciada pelos projetos de software no Brasil, quando ambos se referem à influência de fatores na produtividade do desenvolvimento de software. Persiste a impressão, entretanto, de que a pesquisa e a prática no tema percorrem caminhos distintos. De acordo com este trabalho, a impressão do distanciamento parece estar relacionadas à questão do uso de medidas não-padronizadas e, talvez, inapropriadas para mensurar os fatores e a produtividade do desenvolvimento de softwar

    Supplementary Material for the Paper "Characterizing Software Developers by Perceptions of Productivity"

    No full text
    <p>Contains the survey questions and preprint for the paper "Characterizing Software Developers by Perceptions of Productivity" submitted to ESEM'17. </p> <p>Please contact Thomas Zimmermann ([email protected]) in case you have any questions.</p> <p> </p> <p><strong>Paper Abstract:</strong></p> <p>Understanding developer productivity is important to deliver software on time and at reasonable cost. Yet, there are numerous definitions of productivity and, as previous research found, productivity means different things to different developers. In this paper, we analyze the variation in productivity perceptions based on an online survey with 413 professional software developers at Microsoft. Through a cluster analysis, we identify and describe six groups of developers with similar perceptions of productivity: social, lone, focused, balanced, leading, and goal-oriented developers. We discuss design implications of these clusters for tools to support developers’ productivity.</p

    Supplementary Material for the Paper "Characterizing Software Developers by Perceptions of Productivity"

    No full text
    <p>Contains the survey questions and preprint for the paper "Characterizing Software Developers by Perceptions of Productivity" submitted to ESEM'17. </p> <p>Please contact Thomas Zimmermann ([email protected]) in case you have any questions.</p> <p> </p> <p><strong>Paper Abstract:</strong></p> <p>Understanding developer productivity is important to deliver software on time and at reasonable cost. Yet, there are numerous definitions of productivity and, as previous research found, productivity means different things to different developers. In this paper, we analyze the variation in productivity perceptions based on an online survey with 413 professional software developers at Microsoft. Through a cluster analysis, we identify and describe six groups of developers with similar perceptions of productivity: social, lone, focused, balanced, leading, and goal-oriented developers. We discuss design implications of these clusters for tools to support developers’ productivity.</p
    corecore