Community Smells -- The Sources of Social Debt: A Systematic Literature Review

Context: Social debt describes the accumulation of unforeseen project costs (or potential costs) from sub-optimal software development processes. Community smells are sociotechnical anti-patterns and one source of social debt that impact software teams, development processes, outcomes, and organizations. Objective: To provide an overview of community smells based on published literature, and describe future research. Method: We conducted a systematic literature review (SLR) to identify properties, understand origins and evolution, and describe the emergence of community smells. This SLR explains the impact of community smells on teamwork and team performance. Results: We include 25 studies. Social debt describes the impacts of poor socio-technical decisions on work environments, people, software products, and society. For each of the 30 identified community smells, we provide a description, management approaches, organizational strategies, and mitigation effectiveness. We identify five groups of management approaches: organizational strategies, frameworks, models, tools, and guidelines. We describe 11 properties of community smells. We develop the Community Smell Stages Framework to concisely describe the origin and evolution of community smells. We describe the causes and effects for each community smell. We identify and describe 8 types of causes and 11 types of effects for community smells. Finally, we provide 8 Sankey diagrams that offer insights into threats the community smells pose to teamwork factors and team performance. Conclusion: Community smells explain the influence work conditions have on software developers. The literature is scarce and focuses on a small number of community smells. Thus, community smells still need more research. This review organizes the state of the art about community smells and provides motivation for future research along with educational material.Comment: Accepted for publication in Information and Software Technolog

Technical Debt in Software Development : Examining Premises and Overcoming Implementation for Efficient Management

Software development is a unique field of engineering: all software constructs retain their modifiability — arguably, at least — until client release, no single project stakeholder has exhaustive knowledge about the project, and even this portion of the knowledge is generally acquired only at project completion. These characteristics imply that the field of software development is subject to design decisions that are known to be sub-optimal—either deliberately emphasizing interests of particular stakeholders or indeliberately harming the project due to lack of exhaustive knowledge. Technical debt is a concept that accounts for these decisions and their effects. The concept’s intention is to capture, track, and manage the decisions and their products: the affected software constructs. Reviewing the previous, it is vital for software development projects to acknowledge technical debt both as an enabler and as a hindrance. This thesis looks into facilitating efficient technical debt management for varying software development projects. In the thesis, examination of technical debt’s role in software development produces the premises on to which a management implementation approach is introduced. The thesis begins with a revision of motivations. Basing on prior research in the fields of technical debt management and software engineering in general, the five motivations establish the premises for technical debt in software development. These include notions of subjectivity in technical debt estimation, update frequency demands posed on technical debt information, and technical debt’s polymorphism. Three research questions are derived from the motivations. They ask for tooling support for technical debt management, capturing and modelling technical debt propagation, and characterizing software development environments and their technical debt instances. The questions imply consecutive completion as the first pursued tool would benefit from—possibly automatically assessable—propagation models, and finally the tool’s introduction to software development organizations could be assisted by tailoring it based on the software development environment and the technical debt instance characterizations. The thesis has seven included publications. In introducing them, the thesis maps their backgrounds to the motivations and their outcomes to the research questions. Amongst the outcomes are the DebtFlag tool for technical debt management, the procedures for retrospectively capturing technical debt from software repositories, a procedure for technical debt propagation model creation from these retrospectives, and a multi-national survey characterizing software development environments and their technical debt instances. The thesis concludes that the tooling support, the technical debt propagation modelling, and the software environment and technical debt instance characterization describe an implementation approach to further efficient technical debt management. Simultaneously, future work is implied as all previously described efforts need to be continued and extended. Challenges also remain in the introduced approach. An example of this is the combinatorial explosion of technology-development-context-combinations that technical debt propagation modelling needs to consider. All combinations have to be managed if exhaustive modelling is desired. There is, however, a great deal of motivation to pursue these efforts when one re-notes that technical debt is a permanent component of software development that, when correctly managed, is a development efficiency mechanism comparable to a financial loan investment.Ohjelmistokehitys on uniikki tekniikan ala: kaikki ohjelmistorakenteet säilyttävät muokattavuutensa — otaksuttavasti ainakin — asiakasjulkaisuun asti. Yhdenkään projektiosakkaan tietämys ei kata koko projektia ja merkittävä osa tästäkin tiedosta karttuu vasta projektin suorittamisen aikana. Nämä ominaisuudet antavat ymmärtää, että ohjelmistokehitysala on sellaisten suunnitelupäätösten kohde, joiden tiedetään olevan epätäydellisiä—joko tarkoituksella tiettyjen projektiosakkaiden intressejä painottavia tai tahattomasti projektia vahingoittavia puutteelliseen tietoon perustuvia. Tekninen velka on konsepti, joka huomioi nämä päätökset sekä niiden vaikutukset. Konseptin tarkoitus on havaita, seurata ja hallita näitä päätöksiä sekä tuloksena syntyviä teknisen velan vaikutuksen alla olevia ohjelmistorakenteita. Edellisen kuvauksen valossa ohjelmistokehitysprojekteille on erityisen tärkeää huomioida tekninen velka sekä mahdollistajana että hidasteena. Tämän vuoksi kyseinen väitöskirja perehtyy tehokkaan teknisen velan hallinnan fasilitointiin moninaisille ohjelmistokehitysprojekteille. Väitöskirjassa tarkastellaan teknisen velan roolia osana ohjelmistokehitystä. Tarkastelu tuottaa joukon premissejä, joihin perustuen esitellään lähestymistapa teknisen velan hallinnan toteuttamiselle. Viisi väitöskirjan alussa esitettyä motivaatiota kiinnittävät ne premissit,joille ratkaisu esitetään. Motivaatiot rakennetaan olemassa olevaan teknisen velan sekä ohjelmistotekniikan tutkimustietoon perustuen. Näihin lukeutuvat muun muassa subjektiivisuus teknisen velan estimoinnissa, teknisen velan informaatiolle nähdyt päivitystaajuusvaatimukset sekä teknisen velan polymorfismi. Havainnoista johdetaan kolme tutkimuskysymystä. Ne tavoittelevat työkalutukea teknisen velan hallinnalle, velan propagoitumisen havainnointia sekä mallinnusta kuin myös ohjelmistotuotantoympäristöjen ja niiden velka instanssien kuvaamista. Tutkimuskysymykset implikoivat peräkkäistä suoritusta: tavoiteltu työkalu hyötyy—mahdollisesti automaattisesti arvoitavista—teknisen velan propagaatiomalleista. Valmiin työkalun käyttöönottoa voidaan taas edistää jos kuvaukset kehitysympäristöistä sekä niiden velkainstansseista ovat käytettävissä työkalun räätälöintiin. Väitöskirjaaan sisältyy seitsemän julkaisua. Väitöskirja esittelee ne kiinnittämällä julkaisujen taustatyön aikaisemmin mainittuihin motivaatioihin sekä niiden tulokset edellisiin tutkimuskysymyksiin. Tuloksista huomioidaan esimerkiksi DebtFlag-työkalu teknisen velan hallintaan, retrospektiivinen prosessi teknisen velan kartoittamiselle versionhallintajärjestelmistä, prosessi teknisen velan mallien rakentamiselle näistä kartoituksista ja monikansallinen kyselytutkimus ohjelmistokehitysympäristöjen sekä näiden teknisen velan instanssien luonnehtimiseksi. Väitöskirjan yhteenvetona huomioidaan, että teknisen velan hallinnan työkalutuki, teknisen velan propagaatiomallinnus ja ohjelmistokehitysympäristöjen sekä niiden teknisen velan instanssien luonnehdinta muodostavat toteutustavan, jolla teknisen velan tehokasta hallintaa voidaan kehittää. Samalla implikoidaan jatkotoimia, sillä kaikkia edellä kuvattuja työn osia tulee jatkaa ja laajentaa. Toteutustavalle nähdään myös haasteita. Eräs näistä on kombinatorinen räjähdys teknologia- ja kehityskontekstikombinaatioille. Kaikki kombinaatiot tulee huomioida mikäli teknisen velan propagaatiomallinnuksesta halutaan kattavaa. Motivaatio väitöskirjassa esitetyn työn jatkamiselle on huomattavaa ja sitä kasvattaa entuudestaan edellä tehty huomio siitä, että tekninen velka on pysyvä komponentti ohjelmistokehityksessä, joka oikein hallittuna on kehitystehokkuutta edistävänä komponenttina verrattavissa finanssialan lainainvestointiin.Siirretty Doriast

“The Second Vice is Lying, the First is Running into Debt.” Antecedents and Mitigating Practices of Social Debt: an Exploratory Study in Distributed Software Development Teams

Although much is known about the concept of technical debt in software development, less is known about its social counterpart, also known as social debt. Social debt refers to future consequences of decisions related to people and their interactions. Omissions in social interactions or reduction of communication can foster social debt – and in turn result in negative outcomes in the long run. In this paper, we explore what factors drive and mitigate social debt in distributed agile software development teams. Utilizing an exploratory case study approach, we derive insights from two case organizations. We present antecedents and mitigating factors of social debt related to communication, collaboration, and coordination

Project success in Agile –driven software delivery projects

Agile project methodology is adopted by large in software industry all over the world. The methodology is based on Agile Manifesto that was announced by a group of software devel-opers in 2001. Since then, a number of Agile methodologies and methods including their own processes, were created. Along Agile, the concept of project success changed from project management success to project success, latter highlighting especially client satisfaction. The purpose of this study was to clarify what are the perceptions on project success in the Agile –driven commercial software delivery projects, examined from client´s and supplier´s perspec-tive, and whether those expectations are fulfilled. The backbone of the study was the Agile research in which the concepts of project success, success factors and risks were presented. Based on study findings, the project success is perceived differently by project stakeholders, depending on the role of the stakeholder and his/her level of understanding Agile. The per-ceptions are different not only between the stakeholders but inside the client and supplier organizations themselves. The study proposes that the project methodology as well as objec-tives of the projects are discussed with the actual project stakeholders already during the contract phase so that both sides can commit and have joint understanding of the goals be-fore the actual project starts. The study also recommends that the outcomes are measured against the agreed objectives upon project completion

Splicing Community and Software Architecture Smells in Agile Teams: An industrial Study

Software engineering nowadays largely relies on agile methods to carry out software development. In often highly distributed organizations, agile teams can develop organisational and socio-technical issues loosely defined as community smells, which reflect sub-optimal organisational configurations that bear additional project cost, a phenomenon called social debt. In this paper we look into the co-occurrence of such nasty organisational phenomena—community smells—with software architecture smells—indicators that software architectures may exhibit sub-optimal modularization structures, with consequent additional cost. We conclude that community smells can serve as a guide to steer the qualities of software architectures within agile teams

Success Factors as Critical That Shape Agile Software Development Project Success

This study has implications for positive social change because organizations that understand the critical factors may be able to improve project management strategies and cost benefits leading to higher efficiency, profitability, and productivity thus benefiting management, employees, and customers. Information technology (IT) project success depends on having a project manager with effective decision-making, leadership, and project management skills. Project success also depends on completing the project in a given budget, time, and scope. However, there is a limited understanding of the lived experiences of agile managers and the following success factors: engineering, management, organization, and stakeholders. The purpose of this phenomenological study was to understand these lived experiences of 10 agile software development team project managers or leaders at global workplaces based in the United States. The research questions were focused on the effect of these success factors on agile software development project success. In accordance with nonrandom purposeful sampling strategies, a snowball technique was used to find more participants. An open-ended, e-mail questionnaire was created and sent to participants to collect data. The data were coded to discern themes or patterns. According to study results, agile software development team employs automate builds, continuous integration, and design patterns help reduce technical debt; good collaboration and communication skills are core to project success; product owner helps maximize business value delivered by team and priority and engage stakeholders; and sponsors help fund the project and other resources

A CONSOLIDATED UNDERSTANDING OF TECHNICAL DEBT

Technical debt utilises financial debt as a metaphor to describe the phenomenon of increasing software development costs over time. Whilst this phenomenon is evidently detrimental to the long-term success of software development, it appears to be poorly understood in the academic literature. The absence of a clear definition and model for technical debt means that the notion of technical debt remains metaphorical, thus preventing the realisation of technical debt\u27s utility as a conceptual and technical communication device. This exploratory study reconciles the high-level, abstracted view of technical debt presented in academic literature. It establishes the boundaries of the technical debt phenomenon and develops a comprehensive theoretical framework to facilitate future research. The resulting theoretical framework portrays a holistic view of technical debt that incorporates a set of precedents and outcomes, as well as the phenomenon itself

Social Debt in Software Engineering: Insights from Industry

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