Academia.eduAcademia.edu

Outline

Title
Abstract
Introduction
Research Design
Research Problem and Research Question
Research Methodology
Empirical Background
Data Collection
Analysis Methods
Results
Discussion
On the Implications of Social Debt
Conclusions and Future Work
References
All Topics
Computer Science
Software Engineering

Social debt in software engineering: insights from industry

Profile image of Patricia LagoPatricia Lago

2015, Journal of Internet Services and Applications

https://doi.org/10.1186/S13174-015-0024-6
visibility

…

description

15 pages

link

1 file

Abstract

Social debt is analogous to technical debt in many ways: it represents the state of software development organisations as the result of "accumulated" decisions. In the case of social debt, decisions are about people and their interactions. Our objective was to study the causality around social debt in practice. In so doing, we conducted exploratory qualitative research in a large software company. We found many forces together causing social debt; we represented them in a framework, and captured anti-patterns that led to the debt in the first place. Finally, we elicited best practices that technicians adopted to pay back some of the accumulated debt. We learned that social debt is strongly correlated with technical debt and both forces should be reckoned with together during the software process.

Related papers

Surveying Software Practitioners on Technical Debt Payment Practices and Reasons for not Paying off Debt Items
Boris Erick Pilco Gutierrez

Proceedings of the Evaluation and Assessment in Software Engineering, 2020

Background: Little is known about the practices used for technical debt (TD) payment. The study of payment practices, as well as the reasons for not applying them, can help practitioners to control and manage TD items. Aims: To investigate, from the point of view of software practitioners, if TD items have been paid off in software projects, the practices that have been used to pay off TD and the reasons that hamper the implementation of these practices. Method: We analyzedboth quantitatively and qualitativelya corpus of responses from a survey of 432 practitioners, from four countries, about the possibility of TD payment. Results: We found that, for most of the cases, TD items have not been eliminated from software projects. The main reasons for not paying off TD are lack of organizational interest, low priority on the debt, focus on short-term goals, cost, and lack of time. On the other hand, we identified that code refactoring, design refactoring, and update system documentation are the most used practices for TD payment. Practitioners also cited practices related to the prevention, prioritization, and creation of a favorable setting as part of TD payment initiatives. Conclusion: This paper summarizes the identified practices and reasons for not paying off debt items in a map. Our map reveals that the majority of payment practices are of a technical nature while the majority of reasons for not paying off debts are associated with non-technical issues.

View PDFchevron_right
How Experience Impacts Practitioners' Perception of Causes and Effects of Technical Debt
Carolyn Seaman

2021 IEEE/ACM 13th International Workshop on Cooperative and Human Aspects of Software Engineering (CHASE)

Context: The technical debt (TD) metaphor helps to conceptualize the pending issues and trade-offs made during software development. Knowing TD causes can support in defining preventive actions and having information about effects aids in the prioritization of TD payment. Goal: To investigate the impact of the experience level on how practitioners perceive the most likely causes that lead to TD and the effects of TD that have the highest impacts on software projects. Method: We approach this topic by surveying 227 practitioners. Results: While experienced software developers focus on human factors as TD causes and external quality attributes as TD effects, low experienced developers seem to concentrate on technical issues as causes and internal quality issues and increased project effort as effects. Missing any of these types of causes could lead a team to miss the identification of important TD, or miss opportunities to preempt TD. On the other hand, missing important effects could hamper effective planning or erode the effectiveness of decisions about prioritizing TD items. Conclusion: Having software development teams composed of practitioners with a homogeneous experience level can erode the team's ability to effectively manage TD.

View PDFchevron_right
Technical Debt is not Only about Code and We Need to be Aware about It
Nebojša Taušan

XX Brazilian Symposium on Software Quality

Context: It is common for a software project to incur technical debt (TD) during its development. It can impact several artifacts produced throughout the software development process. Therefore, it is necessary to carry out management actions to find a balance between the benefits of incurring it and the effects of its presence. However, so far, much of the attention has been given only to discussions relating TD to coding issues. This is a worrying scenario because other types of debt can also have impactful, or even worse, consequences on projects. Aims: This study elaborates on the need to consider other issues of the development process and not just the source-code when investigating the TD phenomenon. Method: We analyze responses from 653 practitioners concerning TD causes, effects, prevention, reasons for nonprevention, repayment, and reasons for non-repayment and investigate whether these TD management elements are related to coding or to other software development issues. Results: Coding issues are commonly related to the investigated elements but, indeed, they are only part of the big picture we draw. Issues related to the project planning and management, human factors, knowledge, quality, process, requirements, verification, validation, and test, design, architecture, TD management, and the organization are also common. Lastly, we present a hump diagram that, in combination with the detailed results, provides guidance on what to expect from the presence of TD and how to react to it considering several issues of software development. Conclusion: The results shed light on other concerns beyond code that the research community and practitioners need to be aware of.

View PDFchevron_right
Managing Technical Debt: An Industrial Case Study
Anam XYZ

Technical debt is the consequence of trade-offs made during software development to ensure speedy releases. The research community lacks rigorously evaluated guidelines to help practitioners characterize, manage and prioritize debt. This paper describes a study conducted with an industrial partner during their implementation of Agile development practices for a large software development division within the company. The report contains our initial findings based on ethnographic observations and semi-structured interviews. The goal is to identify the best practices regarding managing technical debt so that the researchers and the practitioners can further evaluate these practices to extend their knowledge of the technical debt metaphor. We determined that the developers considered their own taxonomy of technical debt based on the type of work they were assigned and their personal understanding of the term. Despite management's high-level categories, the developers mostly considered design debt, testing debt and defect debt. In addition to developers having their own taxonomy, assigning dedicated teams for technical debt reduction and allowing other teams about 20% of time per sprint for debt reduction are good initiatives towards lowering technical debt. While technical debt has become a well-regarded concept in the Agile community, further empirical evaluation is needed to assess how to properly apply the concept for various development organizations.

View PDFchevron_right
The influence of Technical Debt on software developer morale
Terese Besker

Journal of Systems and Software, 2020

This is a PDF file of an article that has undergone enhancements after acceptance, such as the addition of a cover page and metadata, and formatting for readability, but it is not yet the definitive version of record. This version will undergo additional copyediting, typesetting and review before it is published in its final form, but we are providing this version to give early visibility of the article. Please note that, during the production process, errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain.

View PDFchevron_right
Technical debt cripples software developer productivity
Terese Besker

2018

Software companies need to continuously deliver customer value, both from a short-and long-term perspective. However, software development can be impeded by what has been described as Technical Debt (TD). The aim of this study is to explore the negative consequences of TD in terms of wasted software development time. This study also investigates on which additional activities this wasted time is spent and whether different types of TD impact the wasted time differently. This study also sets out to examine the benefits of tracking and communicating the amount of wasted time, both from a developer's and manager's perspective. This paper reports the results of a longitudinal study, surveying 43 software developers, together with follow-up interviews with 16 industrial software practitioners. The analysis of the reported wasted time revealed that developers waste, on average, 23% of their development time due to TD and that they are frequently forced to introduce new TD due to already existing TD. The most common activity on which additional time is spent is performing additional testing. CCS CONCEPTS • Software and its engineering → Software creation and management;

View PDFchevron_right
Technical Debt: The Ultimate Antipattern - The Biggest Costs May Be hidden, Widespread, and Long Term
Lawrence Peters

2014 Sixth International Workshop on Managing Technical Debt, 2014

Software projects run the gamut from simple to complex, difficult to impossible and everything in between. Software project managers and their development teams must cope with and adapt to unforeseeable changes in nearly every aspect of the project as originally envisioned, scheduled and planned. In spite of all this turmoil and chaos systems get built, they work and at a later time are seen as having been created via a variety of imprudent development practices now collectively referred to as technical debt. This paper examines the hidden cost of expediency by probing what taking shortcuts does to productivity, morale and turnover on the project identifying debt that goes much deeper than technical.

View PDFchevron_right
Investigating the point of view of project management practitioners on technical debt
Manoel Mendonça

Proceedings of the International Conference on Technical Debt

Context: Technical debt (TD) can bring short-term benefits to software projects, but its presence is also associated with issues such as decreasing product quality. Recent literature has proposed indicator-based strategies for TD identification and different approaches for TD management, but most of them focused on the point of view of software developers. Little is still known about how project management practitioners actually discuss, experience, and manage TD. Goal: This work investigates, from the point of view of project management practitioners, how they commonly discuss, experience, and manage TD. Method: We mined, curated, and selected a total of 42 TD discussions on Stack Exchange Project Management (SEPM), totaling 583 messages. We analyzed this data set quantitatively and qualitatively. Results: The most commonly discussed types of debt are process and people, revealing 47 indicators for recognizing debt items. We also found 72 practices related to TD management. Conclusion: The perspective considered by project management practitioners to analyze the TD phenomenon is different from the one considered by other roles in the software development process. This work organizes the TD indicators and management practices identified in SEPM into a Sankey diagram, which may assist practitioners and serve as guidance for future research.

View PDFchevron_right
Building and evaluating a theory of architectural technical debt in software-intensive systems
Ivano Malavolta

J. Syst. Softw., 2021

Architectural technical debt in software-intensive systems is a metaphor used to describe the ‘‘big’’ design decisions (e.g., choices regarding structure, frameworks, technologies, languages, etc.) that, while being suitable or even optimal when made, significantly hinder progress in the future. While other types of debt, such as code-level technical debt, can be readily detected by static analyzers, and often be refactored with minimal or only incremental efforts, architectural debt is hard to be identified, of wide-ranging remediation cost, daunting, and often avoided. In this study, we aim at developing a better understanding of how software development organizations conceptualize architectural debt, and how they deal with it. In order to do so, in this investigation we apply a mixed empirical method, constituted by a grounded theory study followed by focus groups. With the grounded theory method we construct a theory on architectural technical debt by eliciting qualitative data ...

View PDFchevron_right
An Empirical Investigation of the Harmfulness of Architectural Technical Debt
Terese Besker

2018

Background: In order to survive in today's fast-growing and ever fast-changing business environments, large-scale software companies need to deliver customer value continuously, both from a short- and long-term perspective. However, the consequences of potential long-term and far-reaching negative effects of shortcuts and quick fixes made during the software development lifecycle, described as Technical Debt (TD), can impede the software development process. Objective: The overall goal of this Licentiate thesis is to empirically study and understand in what way and to what extent, TD in general and architectural TD specifically, influence today’s software development work and, specifically, with the intention of providing more quantitative insights into the field. Method: To achieve the objectives, a combination of both quantitative and qualitative research methodologies are used, including interviews, surveys, a systematic literature review, a longitudinal study, correlation an...

View PDFchevron_right

References (45)

  1. Keyes, J.: Social Software Engineering. Taylor & Francis, Auerbach Series, Boca Raton, FL (2011)
  2. Tamburri, D.A., di Nitto, E., Lago, P., van Vliet, H.: On the nature of the GSE organizational social structure: an empirical study. Proceedings of the 7th IEEE International Conference on Global Software Engineering, 114-123 (2012)
  3. Tamburri, D.A., Kruchten, P., Lago, P., van Vliet, H.: What is social debt in software engineering? In: Cooperative and Human Aspects of Software Engineering (CHASE), 2013 6th International Workshop On, pp. 93-96 (2013).
  4. Tamburri, D.A., Lago, P., van Vliet, H.: Uncovering latent social communities in software development. IEEE Software 30(1), 29-36 (2013). doi:10.1109/MS.2012.170
  5. Tamburri, D.A., Lago, P., van Vliet, H.: Organizational social structures for software engineering. ACM Comput. Surv. 46(1), 3 (2013)
  6. Capek, P.G., Frank, S.P., Gerdt, S., Shields, D.: A history of ibm's open-source involvement and strategy. IBM Systems Journal 44(2), 249-258 (2005)
  7. Kruchten, P., Nord, R.L., Ozkaya, I.: Technical debt: From metaphor to theory and practice. IEEE Software 29(6), 18-21 (2012)
  8. Cunningham, W.: The WyCash portfolio management system. OOPS Messenger 4(2), 29-30 (1993)
  9. Zazworka, N., Shaw, M.A., Shull, F., Seaman, C.: Investigating the impact of design debt on software quality. In: Proceedings of the 2nd Workshop on Managing Technical Debt. MTD '11, pp. 17-23. ACM, New York, NY, USA (2011). doi:10.1145/1985362.1985366. http://doi.acm.org/10.1145/1985362.1985366
  10. Conway, M.E.: How do committees invent. Datamation 14(4), 28-31 (1968)
  11. Wenger, E., McDermott, R.A., Snyder, W.: Cultivating Communities of Practice: a Guide to Managing Knowledge, p. . Harvard Business School Publishing, (2002)
  12. Nagappan, N., Murphy, B., Basili, V.: The influence of organizational structure on software quality: an empirical case study. In: International Conference on Software Engineering, pp. 521-530. IEEE, Leipzig, Germany (2008)
  13. Repenning, A., Ahmadi, N., Repenning, N., Ioannidou, A., Webb, D., Marshall, K.: Collective programming: making end-user programming (more) social, 325-330
  14. Viana, D., Conte, T., Vilela, D., de Souza, C.R.B., Santos, G., Prikladnicki, R.: The influence of human aspects on software process improvement: Qualitative research findings and comparison to previous studies. In: EASE, pp. 121-125 (2012)
  15. Meneely, A., Williams, L., Snipes, W., Osborne, J.A.: Predicting failures with developer networks and social network analysis. In: Harrold, M.J., Murphy, G.C. (eds.) SIGSOFT FSE, pp. 13-23. ACM, (2008)
  16. Cataldo, M., Herbsleb, J.D., Carley, K.M.: Socio-technical congruence: a framework for assessing the impact of technical and work dependencies on software development productivity. In: Proceedings of the Second ACM-IEEE International Symposium on Empirical Software Engineering and Measurement. ESEM '08, pp. 2-11. ACM, New York, NY, USA (2008).
  17. Cataldo, M., Mockus, A., Roberts, J.A., Herbsleb, J.D.: Software dependencies, work dependencies, and their impact on failures. IEEE Trans. Software Eng. 35(6), 864-878 (2009)
  18. Kwan, I., Schroter, A., Damian, D.: Does socio-technical congruence have an effect on software build success? a study of coordination in a software project. IEEE Transactions on Software Engineering 37(3), 307-324 (2011). doi:10.1109/TSE.2011.29
  19. de Souza, C.R.B., Redmiles, D.F.: The Awareness Network, To Whom Should I Display My Actions? And, Whose Actions Should I Monitor? IEEE Trans. Software Eng. 37(3), 325-340 (2011)
  20. Bird, C., Nagappan, N., Gall, H., Murphy, B., Devanbu, P.: Putting it all together: Using socio-technical networks to predict failures. In: Proceedings of the 2009 20th International Symposium on Software Reliability Engineering. ISSRE '09, pp. 109-119. IEEE Computer Society, Washington, DC, USA (2009). doi:10.1109/ISSRE.2009.17
  21. Cusick, J.J., Prasad, A.: A practical management and engineering approach to offshore collaboration. IEEE Software 23(5), 20-29 (2006)
  22. Jaktman, C.B.: The influence of organisational factors on the success and quality of a product-line architecture. In: Australian Software Engineering Conference, pp. 2-11. IEEE Computer Society, ??? (1998)
  23. Andreou, A.S.: Promoting software quality through a human, social and organisational requirements elicitation process. Requir. Eng. 8(2), 85-101 (2003)
  24. Meverson, E.M.: Human capital, social capital and compensation: The relative contribution of social contacts to managers' incomes. Acta Sociologica 37(4), 383-399 (1994)
  25. Labianca, G., Brass, D.J.: Exploring the social ledger: Negative relationships and negative asymmetry in social networks in organizations. The Academy of Management Review 31(3), 596-614 (2006)
  26. Muir, D.E.: The social debt: An investigation of lower-class and middle class norms of social obligation. American Sociological Review (1962)
  27. Moe, N.B., Smite, D.: Understanding a lack of trust in global software teams: a multiple-case study. Software Process: Improvement and Practice 13(3), 217-231 (2008)
  28. Atkinson, R., Flint, J.: Accessing hidden and hard-to-reach populations: Snowball research strategies (2012)
  29. Neville-Neil, G.: Interviewing techniques. ACM Queue 9(6), 30 (2011)
  30. Morgan, D.L., Krueger, R.A.: 1. In: Morgan, D.L. (ed.) When to use focus groups and why, pp. 3-19. SAGE Publications, ??? (1993)
  31. Runeson, P., Höst, M.: Guidelines for conducting and reporting case study research in software engineering. Empirical Software Engineering 14(2), 131-164 (2009)
  32. Corbin, J., Strauss, A.: Grounded theory research: Procedures, canons, and evaluative criteria. Qualitative Sociology 13(1), 3-21 (1990)
  33. Schreiber, C., Carley, K.M.: Going beyond the data: Empirical validation leading to grounded theory. Computational & Mathematical Organization Theory 10(2), 155-164 (2004)
  34. Onions, P.E.W.: Grounded theory applications in reviewing knowledge management literature. Leeds Metropolitan University Innovation North Research Conference (1962), 1-20 (2006)
  35. Glaser, B.G.: Theoretical Sensitivity: Advances in the Methodology of Grounded Theory. Sociology Press, San Francisco, CA (1978)
  36. Kilduff, M., Tsai, W.: Social Networks and Organizations, p. 172. Sage Publications Ltd, (2003)
  37. Chisan, J., Damian, D.: Towards a model of awareness support of software development in gsd. IEE Seminar Digests 2004(912), 28-33 (2004). doi:10.1049/ic:20040309
  38. Peng, Y., Sutanto, J.: Facilitating knowledge sharing through a boundary spanner. IEEE Trans. Prof. Communication 55(2), 142-155 (2012)
  39. Labs, P.: "2013 state of devops report". "Technical Report" "Available Online" (2013)
  40. Li, M., Chen, G., Zhang, Z., Fu, Y.: A social collaboration platform for enterprise social networking. In: Gao, L., Shen, W., Barths, J.-P.A., Luo, J., Yong, J., Li, W., Li, W. (eds.) CSCWD, pp. 671-677. IEEE, (2012)
  41. Swart, J., Henneberg, S.C.: Dynamic knowledge nets -the 3c model: exploratory findings and conceptualisation of entrepreneurial knowledge constellations. J. Knowledge Management 11(6), 126-141 (2007)
  42. Boella, G., van der Torre, L.: Coordination and organization: Definitions, examples and future research directions. Electronic Notes in Theoretical Computer Science (ENTCS) 150(3), 3-20 (2006)
  43. Manteli, C., van der Hooff, B., van Vliet, H.: The Effect of Governance on Global Software Development: An Empirical Research in Transactive Memory Systems. Information and Software Technology 56(10), 1309-1321 (2014)
  44. Wohlin, C., Runeson, P., Höst, M., Ohlsson, M.C., Regnell, B., Wesslén, A.: Experimentation in Software Engineering: an Introduction. Kluwer Academic Publishers, Norwell, MA, USA (2000)
  45. Tamburri, D.A.: Going global with agile service networks. International Conference on Software Engineering (2012)

Related papers

What Is Social Debt in Software Engineering?
Philippe Kruchten

Social debt" in software engineering informally refers to unforeseen project cost connected to a "suboptimal" development community. The causes of suboptimal development communities can be many, ranging from global distance to organisational barriers to wrong or uninformed socio-technical decisions (i.e., decisions that influence both social and technical aspects of software development). Much like technical debt, social debt impacts heavily on software development success. We argue that, to ensure quality software engineering, practitioners should be provided with mechanisms to detect and manage the social debt connected to their development communities. This paper defines and elaborates on social debt, pointing out relevant research paths. We illustrate social debt by comparison with technical debt and discuss common real-life scenarios that exhibit "sub-optimal" development communities.

View PDFchevron_right
When Software Architecting Leads to Social Debt
Damian Andrew Tamburri

Social and technical debt both represent the state of software development organizations as a result of accumulated decisions. In the case of social debt, decisions (and connected debt) weigh on people and their socio-technical interactions/characteristics. Digging deeper into social debt with an industrial case-study, we found that software architecture, the prince of development artefacts, plays a major role in causing social debt. For example, we found that “lonesome” architects are more likely to generate debt and that “invisible” architecting might be increasing this debt. This paper discusses circumstances wherefore social debt is connected to software architectures and what can be done in response, as observed in our case-study.

View PDFchevron_right
Measure it? Manage it? Ignore it? software practitioners and technical debt
Ian Gorton

Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering, 2015

The technical debt metaphor is widely used to encapsulate numerous software quality problems. The metaphor is attractive to practitioners as it communicates to both technical and nontechnical audiences that if quality problems are not addressed, things may get worse. However, it is unclear whether there are practices that move this metaphor beyond a mere communication mechanism. Existing studies of technical debt have largely focused on code metrics and small surveys of developers. In this paper, we report on our survey of 1,831 participants, primarily software engineers and architects working in long-lived, software-intensive projects from three large organizations, and follow-up interviews of seven software engineers. We analyzed our data using both nonparametric statistics and qualitative text analysis. We found that architectural decisions are the most important source of technical debt. Furthermore, while respondents believe the metaphor is itself important for communication, existing tools are not currently helpful in managing the details. We use our results to motivate a technical debt timeline to focus management and tooling approaches.

View PDFchevron_right
Looking for Peace of Mind? Manage Your (Technical) Debt: An Exploratory Field Study
Terese Besker

2017

Background: In the last two decades Technical Debt (TD) has received a considerable amount of attention from software engineering research and practice. Recently, a small group of studies suggests that, in addition to its technical and economic consequences, TD can affect developers' psychological states and morale. However, until now there has been a lack of empirical research clarifying such influences. Aims: In this study, we aim at taking the first step in filling this gap by investigating the potential impacts of TD and its management on developers' morale. Method: Drawing from previous literature on morale, we decided to explore the influence of TD and its management on three dimensions of morale called affective, future/goal, and interpersonal antecedents. In so doing, we conducted an exploratory field study and collected data from software professionals active in different industrial domains through eight qualitative interviews and an online survey (n=33). Results: Our results indicate that TD mainly has a negative influence on future/goal and affective antecedents of morale. This is mainly because the occurrence of TD hinders developers from performing their tasks and achieving their goals. TD management, on the other hand, has a positive influence on all the three dimensions of morale since it is associated with positive feelings and interpersonal feedback as well as a sense of progress. Conclusions: According to the results of this empirical study, the occurrence of TD reduces developers' morale, while its management increases developers' morale.

View PDFchevron_right
Investigating the Relationship between Technical Debt Management and Software Development Issues
Clemente Izurieta

Journal of Software Engineering Research and Development

Context: The presence of technical debt (TD) brings risks to software projects. Managers must continuously find a cost-benefit balance between the benefits of incurring in TD and the costs of its presence in a software project. Much attention has been given to TD related to coding issues, but other types of debt can also have impactful consequences on projects. Aims: This paper seeks to elaborate on the growing need to expand TD research to other areas of software development, by analyzing six elements related to TD management, namely: causes, effects, preventive practices, reasons for non-prevention, repayment practices, and reasons for non-repayment of TD. Method: We survey and analyze, quantitatively and qualitatively, the answers of 653 software industry practitioners on TD to investigate how the previously mentioned elements are related to coding and non-coding issues of the software development process. Results: Coding issues are commonly related to the investigated elements b...

View PDFchevron_right

Related topics

  • Software Process Improvement and...
  • Managing Technical Debt
  • Social Debt in Software Engineering

    • Cited by

    Refactoring Community Smells in the Wild: The Practitioner’s Field Manual
    Damian Andrew Tamburri

    2020 IEEE/ACM 42nd International Conference on Software Engineering: Software Engineering in Society (ICSE-SEIS), 2020

    Community smells have been defined as sub-optimal organizational structures that may lead to social debt. Previous studies have shown that they are highly diffused in both open- and closed-source projects, are perceived as harmful by practitioners, and can even lead to the introduction of technical debt in source code. Despite the presence of this body of research, little is known on the practitioners’ perceived prominence of community smells in practice as well as on the strategies adopted to deal with them. This paper aims at bridging this gap by proposing an empirical study in which 76 software practitioners are inquired on (i) the prominence of four well-known community smells, i.e., Organizational Silo, Black Cloud, Lone Wolf, and Radio Silence, in their contexts and (ii) the methods they adopted to “refactor” them. Our results first reveal that community smells frequently manifest themselves in software projects and, more importantly, there exist specific refactoring practices...

    View PDFchevron_right
    Omniscient DevOps Analytics
    Damian Andrew Tamburri

    2018

    DevOps predicates the continuity between Development and Operations teams at an unprecedented scale. Also, the continuity does not stop at tools, or processes but goes beyond into organizational practices, collaboration, co-located and coordinated effort. We conjecture that this unprecedented scale of continuity requires predictive analytics which are omniscient, that is (i) transversal to the technical, organizational, and social stratification in software processes and (ii) correlate all strata to provide a live and holistic snapshot of software development, its operations, and organization. Elaborating this conjecture, we illustrate a set of metrics to be used in the DevOps scenario and overview challenges and future research directions.

    View PDFchevron_right
    Interpersonal Conflicts During Code Review
    Pavlína Wurzel Gonçalves

    Proceedings of the ACM on Human-Computer Interaction

    Code review consists of manual inspection, discussion, and judgment of source code by developers other than the code's author. Due to discussions around competing ideas and group decision-making processes, interpersonal conflicts during code reviews are expected. This study systematically investigates how developers perceive code review conflicts and addresses interpersonal conflicts during code reviews as a theoretical construct. Through the thematic analysis of interviews conducted with 22 developers, we confirm that conflicts during code reviews are commonplace, anticipated and seen as normal by developers. Even though conflicts do happen and carry a negative impact for the review, conflicts-if resolved constructively-can also create value and bring improvement. Moreover, the analysis provided insights on how strongly conflicts during code review and its context (i.e., code, developer, team, organization) are intertwined. Finally, there are aspects specific to code review con...

    View PDFchevron_right
    Seeking new measures for gender bias effects in open-source software
    Huilian Sophie Qiu

    Proceedings of the 15th International Conference on Cooperative and Human Aspects of Software Engineering

    The problem of low gender diversity in open-source software (OSS) has been reported and studied in recent years. However, prior studies found that gender bias theories in social sciences cannot help us effectively identify gender bias effects in OSS. Our study takes the first step toward finding new measures for gender bias in OSS. This paper attempts to employ linguistic theories to identify different collaboration patterns between different genders. Our contributions are twofold: we review linguistic literature on diversity and online collaboration, then we apply linguistic theories from our literature reviews to a random sample of code review conversations on GitHub. 1 INTRODUCTION The low gender diversity in the open-source software (OSS) community is a well-known phenomenon: among the GitHub users whose genders can be inferred, less than 10% are women [1, 6, 15, 30]. The low gender diversity is problematic as it can threaten OSS sustainability as a whole. Firstly, low gender diversity is suboptimal for project success: studies found that higher gender diversity is associated with fewer community smells [7, 38] and higher team performance [26, 34, 40]. Moreover, the highly imbalanced gender representation and the unwelcoming culture in some open-source projects [23] may discourage underrepresented groups from initial participation, which limits opportunities both for those individuals and for employers that use OSS as a talent pool [32, 33]. One of the reasons for women's low participation is gender bias [19, 23, 39]. Based on interviews with OSS developers, Nafus [23] pointed out that, in OSS, "sexist behavior is [...] as constant as it is extreme. " A quantitative study by Terrell et al. [39] reports that female contributors face unfair treatments when making code contributions. This piece of work builds upon a prior attempt on investigating gender bias effects in OSS by Imtiaz et al. [19]. In their paper, Imtiaz et al. adapted a gender bias framework by Williams and Dempsey [42], which was developed for women in the workforce, to the context of OSS. The framework discusses four effects of gender bias women may face in the workforce. Prove-It-Again: women

    View PDFchevron_right
    Technical Debt is not Only about Code and We Need to be Aware about It
    Sávio Freire

    XX Brazilian Symposium on Software Quality

    Context: It is common for a software project to incur technical debt (TD) during its development. It can impact several artifacts produced throughout the software development process. Therefore, it is necessary to carry out management actions to find a balance between the benefits of incurring it and the effects of its presence. However, so far, much of the attention has been given only to discussions relating TD to coding issues. This is a worrying scenario because other types of debt can also have impactful, or even worse, consequences on projects. Aims: This study elaborates on the need to consider other issues of the development process and not just the source-code when investigating the TD phenomenon. Method: We analyze responses from 653 practitioners concerning TD causes, effects, prevention, reasons for nonprevention, repayment, and reasons for non-repayment and investigate whether these TD management elements are related to coding or to other software development issues. Results: Coding issues are commonly related to the investigated elements but, indeed, they are only part of the big picture we draw. Issues related to the project planning and management, human factors, knowledge, quality, process, requirements, verification, validation, and test, design, architecture, TD management, and the organization are also common. Lastly, we present a hump diagram that, in combination with the detailed results, provides guidance on what to expect from the presence of TD and how to react to it considering several issues of software development. Conclusion: The results shed light on other concerns beyond code that the research community and practitioners need to be aware of.

    View PDFchevron_right
    580 California St., Suite 400
    San Francisco, CA, 94104
    © 2025 Academia. All rights reserved