Managing Technical Debt

This study used Netflix's aggregated data for Top 10 weekly rankings from 2021 to 2023 to perform a predictive analysis of streaming content demand. The scoring system used in this study could compare performance across 10 countries (reflecting high and low engagement levels across 5 global regions) and revealed some indications of how language, culture, and content format influenced viewer engagement over time. The data set was analyzed using a cumulative point system based on weekly rankings, which examined content visibility, moving beyond raw view counts or platform algorithms. The study revealed an international preference for serialized TV shows, as opposed to films, and content with cultural specificity, such as telenovelas in Latin America, anime in Japan, and Korean dramas in South Asia, revealed longer visibility. We were also able to demonstrate that language fits in well with regional storytelling traditions to influence sustained viewer engagement. These results lent support to the view of cultural proximity in digital content consumption and suggested practical advice for improving content localization, especially in less-performing regions. Ultimately, we conclude that sustainable success in streaming global content will depend not only on global trends but also on meaningful engagement at the local and regional level.

a series of events covering a broad spectrum of software-related topics. The conference covered fundamentals on designing, implementing, testing, validating and maintaining various kinds of software. The tracks treated the topics from theory to practice, in terms of methodologies, design, implementation, testing, use cases, tools, and lessons learnt. The conference topics covered classical and advanced methodologies, open source, agile software, as well as software deployment and software economics and education. The conference had the following tracks:  Advances in fundamentals for software development  Advanced mechanisms for software development  Advanced design tools for developing software  Software engineering for service computing (SOA and Cloud)  Advanced facilities for accessing software  Software performance  Software security, privacy, safeness  Advances in software testing  Specialized software advanced applications  Web Accessibility  Open source software  A...

Technical debt is a metaphor used to convey the idea that doing things in a "quick and dirty" way when designing and constructing a software leads to a situation where one incurs more and more deferred future expenses. Similarly to financial debt, technical debt requires payment of interest in the form of the additional development effort that could have been avoided if the quick and dirty design choices have not been made. Technical debt applies to all the aspects of software development, spanning from initial requirements analysis to deployment, and software evolution. Technical debt is becoming very popular from scientific and industrial perspectives. In particular, there is an increase in the number of related papers over the years. There is also an increase in the number of related tools and of their adoption in the industry, especially since technical debt is very pricey and therefore needs to be managed. However, techniques to estimate technical debt are inadequate, insufficient since they mostly focus on requirements, code, and test, disregarding key artifacts such as the software architecture and the technologies used by the software at hand. Besides, despite its high relevance, technical debt prediction is one of the least explored aspects of technical debt. To address these shortcomings, it is mandatory that I undertake research to: 1) improve existing techniques to properly estimate technical debt; 2) to determine the extent to which the use of prediction techniques to foresee and therefore avoid technical debt could help companies save money and avoid a potential bankruptcy in the subsequent years. The proposed research can have an important economic impact by helping companies save several millions. It can have a major scientific impact by leading to key findings that will be disseminated through patents, well-established scientific journals and conferences.

In this paper, the researcher will delve into the concept of technical debt within the Subscription Video-on-Demand (SVOD) industry, analysing its expansion and the challenges it presents. The researcher will explore the various factors contributing to the accumulation of technical debt in the SVOD industry, including rapid growth, evolving technologies, and increasing consumer demands. Furthermore, the researcher will examine the impact of technical debt on business operations, product development, and customer experience, highlighting the potential risks and consequences it poses for SVOD providers. Drawing on real-life examples and industry insights, this paper aims to provide a comprehensive understanding of the complex dynamics surrounding technical debt in the SVOD industry and offer recommendations for managing and mitigating its effects. Through this analysis, the researcher seeks to contribute to a deeper appreciation of the key issues at play in the evolving landscape of SVOD services and the importance of addressing technical debt as part of strategic decision-making.

Technical debt (TD), a metaphor inspired by the financial debt of economic theory, indicates quality compromises that can yield short-term benefits in the software development process, but may negatively affect the long-term quality of software products. Numerous techniques, methods, and tools have been proposed over the years for estimating and managing TD, providing a variety of options to the developers and project managers of software applications. However, apart from managing TD, predicting its future value is equally important since this knowledge is expected to facilitate decision-making tasks regarding software implementation and maintenance, such as incurring or paying off TD instances. To this end, the purpose of the present study is to (i) summarize the work that has been conducted until today in the field of TD estimation and forecasting, and (ii) to identify existing open issues that have not been adequately addressed yet and require further research. The present survey led to two interesting observations. Firstly, none of the existing TD estimation methods and tools has reached a desired level of maturity, while a large volume of previously uninvestigated metrics and techniques exist that could potentially increase the completeness of TD estimation. Secondly, no notable contributions exist in the field of TD forecasting, indicating that it is a scarcely investigated field. The latter constitutes the main finding of the present literature review, since TD forecasting could lead to the development of practical decision-making mechanisms, which could assist developers and project managers in taking proactive actions regarding TD repayment.

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.

Context: The concept of technical debt is a metaphor that contextualizes problems faced during software evolution that reflect technical compromises in tasks that are not carried out adequately during their development-they can yield short-term benefit to the project in terms of increased productivity and lower cost, but that may have to be paid off with interest later. Objective: This work investigates the current state of the art of technical debt tools by identifying which activities, functionalities and kind of technical debt are handled by existing tools that support the technical debt management in software projects. Method: A systematic mapping study is performed to identify and analyze available tools for managing technical debt based on a set of five research questions. Results: The work contributes with (i) a systematic mappping of current research on the field, (ii) a highlight of the most referenced tools, their main characteristics, their supported technical debt types and activities, and (iii) a discussion of emerging findings and implications for future research. Conclusions: Our study identified 50 TD tools where 42 of them are new tools, and 8 tools extend an existing one. Most of the tools address technical debt related to code, design, and/or architecture artifacts. Besides, the different TD management activities received different levels of attention. For example, TD identification is supported by 80% of the tools, whereas 30% of them handle the TD documentation activity. Tools that deal with TD identification and measurement activities are still predominant. However, we observed that recent tools focusing on TD prevention, replacement, and prioritization activities represent emergent research trends.

a series of events covering a broad spectrum of software-related topics. The conference covered fundamentals on designing, implementing, testing, validating and maintaining various kinds of software. The tracks treated the topics from theory to practice, in terms of methodologies, design, implementation, testing, use cases, tools, and lessons learnt. The conference topics covered classical and advanced methodologies, open source, agile software, as well as software deployment and software economics and education. The conference had the following tracks:  Advances in fundamentals for software development  Advanced mechanisms for software development  Advanced design tools for developing software  Software engineering for service computing (SOA and Cloud)  Advanced facilities for accessing software  Software performance  Software security, privacy, safeness  Advances in software testing  Specialized software advanced applications  Web Accessibility  Open source software  A...

a series of events covering a broad spectrum of software-related topics. The conference covered fundamentals on designing, implementing, testing, validating and maintaining various kinds of software. The tracks treated the topics from theory to practice, in terms of methodologies, design, implementation, testing, use cases, tools, and lessons learnt. The conference topics covered classical and advanced methodologies, open source, agile software, as well as software deployment and software economics and education. The conference had the following tracks:  Advances in fundamentals for software development  Advanced mechanisms for software development  Advanced design tools for developing software  Software engineering for service computing (SOA and Cloud)  Advanced facilities for accessing software  Software performance  Software security, privacy, safeness  Advances in software testing  Specialized software advanced applications  Web Accessibility  Open source software  A...

The management of technical debt and the use of productivity games are important aspects of developing software projects. A productivity game was created in the form of a competitive source control plug-in that rewards technical debt-reducing actions. The plug-in was tested by simulating source control usage with in a small sample project. Analysis showed that the plug-in appropriately assigned scores to developers for debt-reducing and debtincreasing actions. The plug-in has potential practical applications in the management of technical debt in workplace environments. The approach described in this paper is promising, and in future work we plan to test the Build Game plug-in with a wider variety of existing and simulated projects. Additional research is also planned to investigate the impact of the Build Game plug-in on workplace productivity.

To date, several methods and tools for detecting source code and design anomalies have been developed. While each method focuses on identifying certain classes of source code anomalies that potentially relate to technical debt (TD), the overlaps and gaps among these classes and TD have not been rigorously demonstrated. We propose to construct a seminal technical debt landscape as a way to visualize and organize research on the subject.

La identificacion de componentes arquitectonicos es de relevancia para actividades de mantenimiento de software, sin embargo esta es dificultada en muchas ocasiones por la ausencia de documentacion arquitectonica y el volumen de codigo fuente.

La identificacion de componentes arquitectonicos es de relevancia para actividades de mantenimiento de software, sin embargo esta es dificultada en muchas ocasiones por la ausencia de documentacion arquitectonica y el volumen de codigo fuente.

La identificacion de componentes arquitectonicos es de relevancia para actividades de mantenimiento de software, sin embargo esta es dificultada en muchas ocasiones por la ausencia de documentacion arquitectonica y el volumen de codigo fuente.

Hasty software development can produce immediate implementations with source code unnecessarily complex and hardly readable. These small kinds of software decay generate a technical debt that could be big enough to seriously affect future maintenance activities. This work presents an analysis technique for identifying architectural technical debt related to non-uniformity of naming patterns; the technique is based on term frequency over package hierarchies. The proposal has been evaluated on projects of two popular organizations, Apache and Eclipse. The results have shown that most of the projects have frequent occurrences of the proposed naming patterns, and using a graph model and aggregated data could enable the elaboration of simple queries for debt identification. The technique has features that favor its applicability on emergent architectures and agile software development.

Component identification is relevant in maintenance activities but can be hard in scenarios where the volume of source code is high and there is no architecture documentation. This work presents a technique for finding concepts as candidates of architectural components. The technique is based in the frequency of terms that follows naming patterns that are proposed in this work. Projects from Eclipse and Apache, were used for evaluating the technique. The results show terms which match with some popular component types and domain concepts of the software in treatment. The technique has used source code without any architectural documentation showing that could be applied in emergent architectures.

Component identification is relevant in maintenance activities but can be hard in scenarios where the volume of source code is high and there is no architecture documentation. This work presents a technique for finding concepts as candidates of architectural components. The technique is based in the frequency of terms that follows naming patterns that are proposed in this work. Projects from Eclipse and Apache, were used for evaluating the technique. The results show terms which match with some popular component types and domain concepts of the software in treatment. The technique has used source code without any architectural documentation showing that could be applied in emergent architectures.

a series of events covering a broad spectrum of software-related topics. The conference covered fundamentals on designing, implementing, testing, validating and maintaining various kinds of software. The tracks treated the topics from theory to practice, in terms of methodologies, design, implementation, testing, use cases, tools, and lessons learnt. The conference topics covered classical and advanced methodologies, open source, agile software, as well as software deployment and software economics and education. The conference had the following tracks:  Advances in fundamentals for software development  Advanced mechanisms for software development  Advanced design tools for developing software  Software engineering for service computing (SOA and Cloud)  Advanced facilities for accessing software  Software performance  Software security, privacy, safeness  Advances in software testing  Specialized software advanced applications  Web Accessibility  Open source software  A...

Software applications used by contemporary organizations have to be expendable for incorporating additional functional requirements, as well as adaptable regarding ever changing user requirements. As this evolvability has frequently be noted to be lacking in most information systems, Normalized Systems (NS) theory has recently proposed a framework on evolvable modularity. Based on the concept of systems theoretic stability, NS formulates a number theorems, constituting a set of formally proven necessary conditions in order to obtain such evolvability in modular structures. These theorems were argued to strongly align with heuristic (often tacit) best-practice knowledge of experienced software developers. In order to further validate this claim, the present paper will investigate the degree in which the NS theorems align with best-practice software engineering guidelines based on the set of 22 “bad smells in code” as defined by Fowler and Beck. The analysis shows that the avoidance o...

Para mejorar la calidad de las arquitecturas de software se usan patrones, que capturan existencia, experiencia comprobada en el desarrollo del software y ayudan a promover buenas prácticas de diseño [2]. Sin embargo, no está claro cómo realizar la evaluación del efecto de incorporar uno o más de estos patrones en la arquitectura del software. El objetivo de este artículo es presentar la evaluación de la calidad propiciada por los patrones arquitectónicos de [ 3] a través del uso de Experimentos Cuantitativos [6]. Para ello fue necesario aplicar un experimento cuantitativo sobre un software colaborativo: un chat. El experimento fue dividido en seis experimentos elementales, los cuales se fundamentaron en la aplicación de métricas arquitectónicas sobre la arquitectura del chat, integrada con las combinaciones de patrones arquitectónicos. Se evidenció que el uso de patrones mejora características que no habían sido consideradas en la hipótesis. π Esta investigación ha sido financiada por el proyecto FONACIT S1-2001000794

Design patterns are well-known design solutions that are reported to produce substantial benefits with respect to software quality. However, to our knowledge there are no scientific efforts on gathering information on software projects that use design patterns. This paper introduces a web repository of design patterns instances that have been used in open source projects. The usefulness of such a repository lies in the provision of a base of knowledge, where developers can identify reusable components and researchers can find a mined data set. Currently, 141 open source projects have been considered and more than 4500 pattern instances have been found and recorded in the database of the repository. The evaluation of the repository has been performed from an academic and a practical point of view. The results suggest that the repository can be useful for both experienced and inexperienced users. However, the benefits of using the repository are more significant for inexperienced users.

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.

Para mejorar la calidad de las arquitecturas de software se usan patrones, que capturan existencia, experiencia comprobada en el desarrollo del software y ayudan a promover buenas prácticas de diseño [2]. Sin embargo, no está claro cómo realizar la evaluación del efecto de incorporar uno o más de estos patrones en la arquitectura del software. El objetivo de este artículo es presentar la evaluación de la calidad propiciada por los patrones arquitectónicos de [ 3] a través del uso de Experimentos Cuantitativos [6]. Para ello fue necesario aplicar un experimento cuantitativo sobre un software colaborativo: un chat. El experimento fue dividido en seis experimentos elementales, los cuales se fundamentaron en la aplicación de métricas arquitectónicas sobre la arquitectura del chat, integrada con las combinaciones de patrones arquitectónicos. Se evidenció que el uso de patrones mejora características que no habían sido consideradas en la hipótesis. π Esta investigación ha sido financiada por el proyecto FONACIT S1-2001000794

Context It is crucial to understand how reproducible the measurement results in the scientific publications are, as reproducibility is one of the cornerstones of engineering. Objective The goal of this study is to investigate the scientific publications presented at the premier technical debt conferences by understanding how reproducible the reported findings are. Method We conducted a systematic literature review of 135 unique papers published at the “International Workshop on Managing Technical Debt” and the “International Conference on Managing Technical Debt”, the premier scientific conference series on technical debt. Results Only 44 of the investigated 135 papers presented numerical evidence and only 5 papers listed the tools, the availability of the tools, and the version of the tools used. For the rest of the papers additional information would have been needed for the potential reproducibility. One of the published papers even referred to a pornographic site as a source of ...

Modularity is one of the key principles of software design. In order for a software system to be modular, it should be organized into modules that are highly coherent internally, whereas at the same time as independent from other modules as possible. In this paper we explore coupling and cohesion metrics at the software package level-i.e., one of most basic levels of software functional decomposition in object-oriented (OO) systems, with the aim of investigating their relation to the technical debt of each package. Current state-of-the-art tools in TD measurement are working on the source code level, and the extent to which they can unveil limitations at the architecture level (e.g., violations of the modularity principle), has not been explored so far. To achieve this goal, we conducted a case study on 1,200 packages retrieved from 20 well-known open source software projects. The results of the study suggested that current measures of technical debt are able to identify / predict modules that lack modularity, and therefore suffer from Architectural Technical Debt (ATD). The results of the study are discussed both from the practitioners' and researchers' point of view.

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.

Technical debt is a metaphor referring to the consequences of weak software development. Managing technical debt is necessary in order to keep it under control, and several techniques have been developed with the goal of accomplishing this. However, available techniques have grown disperse and managers lack guidance. This paper covers this gap by providing a systematic mapping of available techniques and methods for technical debt management, covering architectural debt, and identifying existing gaps that prevent to manage technical debt efflciently.

Technical Debt is a term begat by Ward Cunningham to signify the measure of adjust required to put a software into that state which it ought to have had from the earliest starting point. Often organizations need to support continuous and fast delivery of customer value both in short and a long-term perspective and later have to compromise with the quality and productivity of the software. So, a simple solution could be to repay the debts as and when they are encountered to avoid maintainability cost and subsequent delays. Therefore, it has become inevitable to identify and come up with techniques so as to know when, what and how TD items to repay. This study aims to explore how to identify, measure and monitor technical debt using SonarQube and PMD.

Context: It is crucial to understand how reproducible the measurement results in the scientific publications are, as reproducibility is one of the cornerstones of engineering.
Objective: The goal of this study is to investigate the scientific publications presented at the premier technical debt conferences by understanding how reproducible the reported findings are.
Method: We conducted a systematic literature review of 135 unique papers published at the "International Workshop on Managing Technical Debt" and the "International Conference on Managing Technical Debt", the premier scientific conference series on technical debt.
Results: Only 44 of the investigated 135 papers presented numerical evidence and only 5 papers listed the tools, the availability of the tools, and the version of the tools used. For the rest of the papers additional information would have been needed for the potential reproducibility. One of the published papers even referred to a pornographic site as a source of a toolset for empirical research.

Context: Technical Debt (TD) quantification has been studied in the literature and is supported by various tools; however, there is no common ground on what information shall be presented to stakeholders. Similarly to other quality monitoring processes, it is desirable to provide several views of quality through a dashboard, in which metrics concerning the phenomenon of interest are displayed. Objective: The aim of this study is to investigate the indicators that shall be presented in such a dashboard, so as to: (a) be meaningful for industrial stakeholders, (b) present all necessary information, and (c) be simple enough so that stakeholders can use them. Method: We explore TD Management (TDM) activities (i.e., measurement, prioritization, repayment) and choose the main concepts that need to be visualized, based on existing literature and toolsupport. Next, we perform a survey with 60 software engineers (i.e., architects, developers, etc.) working for 11 software development companies located in 9 countries, to understand their needs for TDM. Results / Conclusions: The results of the study suggest that different stakeholders need a different view of the quality dashboard, but also some commonalities can be identified. For example, on the one hand, managers are mostly interested in financial concepts, whereas on the other hand developers are more interested in the nature of the problems that exist in the code. The outcomes of this study can be useful to both researchers and practitioners, in the sense that the former can focus their efforts on aspects that are meaningful to industry, whereas the latter to develop meaningful dashboards, with multiple views.

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. This paper discusses a key circumstance wherefore social debt is connected to software architectures and what can be done and measured in response, as observed in our case-study. Also, we introduce DAHLIA, that is “Debt-Aimed arcHitectureLevel Incommunicability Analysis” a framework to elicit some of the causes behind social debt for further analysis.

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

This report documents the program and outcomes of Dagstuhl Seminar 16162, “Managing Technical Debt in Software Engineering.” We summarize the goals and format of the seminar, results from the breakout groups, a definition for technical debt, a draft conceptual model, and a research road map that culminated from the discussions during the seminar. The report also includes the abstracts of the talks presented at the seminar and summaries of open discussions.s of the talks presented at the seminar and summaries of open discussions. Seminar April 17–22, 2016 – http://www.dagstuhl.de/16162 1998 ACM Subject Classification coding tools and techniques, design tools and techniques, management, metrics, software engineering

Social debt has been defined as the presence in a project of costly sub-optimal organizational conditions, e.g., non-cohesive development communities whose members have communication or coordination issues. Community smells are indicators of such sub-optimal organizational structures and may well lead to social debt. Recently, several studies analyzed actors affecting presence of community smells and their harmfulness, or proposed refactoring strategies to mitigate them. However, to the best of our knowledge, there is still a limited understanding of the factors influencing the variability of community smells, namely how they increase/decrease in magnitude over time. In this paper, we aim at conducting the first statistical experimentation on the matter, by analyzing how a set of 40 socio-technical factors, e.g., turnover or communicability, impact the variability of four community smells on a dataset composed of 60 open-source communities. The results of the study reveal that communicability is, in most cases, important to reduce the risk of an increase of community smell instances, while broadening the collaboration network does not always have a positive effect.

DOI to the publisher's website. • The final author version and the galley proof are versions of the publication after peer review. • The final published version features the final layout of the paper including the volume, issue and page numbers. Link to publication General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. • Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain • You may freely distribute the URL identifying the publication in the public portal. If the publication is distributed under the terms of Article 25fa of the Dutch Copyright Act, indicated by the "Taverne" license above, please follow below link for the End User Agreement:

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.

DOI to the publisher's website. • The final author version and the galley proof are versions of the publication after peer review. • The final published version features the final layout of the paper including the volume, issue and page numbers. Link to publication General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. • Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain • You may freely distribute the URL identifying the publication in the public portal. If the publication is distributed under the terms of Article 25fa of the Dutch Copyright Act, indicated by the "Taverne" license above, please follow below link for the End User Agreement:

Software engineering is now more than ever a community effort. Its success often weighs on balancing distance, culture, global engineering practices and more. In this scenario many unforeseen socio-technical events may result into additional project cost or "social" debt, e.g., sudden, collective employee turnover. With industrial research we discovered community smells, that is, sub-optimal patterns across the organisational and social structure in a software development community that are precursors of such nasty socio-technical events. To understand the impact of community smells at large, in this paper we first introduce CODEFACE4SMELLS, an automated approach able to identify four community smell types that reflect socio-technical issues that have been shown to be detrimental both the software engineering and organisational research fields. Then, we perform a large-scale empirical study involving over 100 years worth of releases and communication structures data of 60 open-source communities: we evaluate (i) their diffuseness, i.e., how much are they distributed in open-source, (ii) how developers perceive them, to understand whether practitioners recognize their presence and their negative effects in practice, and (iii) how community smells relate to existing socio-technical factors, with the aim of assessing the interrelations between them. The key findings of our study highlight that community smells are highly diffused in open-source and are perceived by developers as relevant problems for the evolution of software communities. Moreover, a number of state-of-the-art socio-technical indicators (e.g., socio-technical congruence) can be used to monitor how healthy a community is and possibly avoid the emergence of social debt.

Context: The technical debt (TD) concept inspires the development of useful methods and tools that support TD identification and management. However, there is a lack of evidence on how different TD identification tools could be complementary and, also, how human-based identification compares with them. Objective: To understand how to effectively elicit TD from humans, to investigate several types of tools for TD identification, and to understand the developers' point of view about TD indicators and items reported by tools. Method: We asked developers to identify TD items from a real software project. We also collected the output of three tools to automatically identify TD and compared the results in terms of their locations in the source code. Then, we collected developers' opinions on the identification process through a focus group. Results: Aggregation seems to be an appropriate way to combine TD reported by developers. The tools used cannot help in identifying many important TD types, so involving humans is necessary. Developers reported that the tools would help them to identify TD faster or more accurately and that project priorities and current development activities are important to be considered together, along with the values of principal and interest, when deciding to pay off a debt. Conclusion: This work contributes to the TD landscape, which depicts an understanding between different TD types and how they are best discovered.

Context: The technical debt metaphor describes the effect of immature artifacts on software maintenance that bring a short-term benefit to the project in terms of increased productivity and lower cost, but that may have to be paid off with interest later. Much research has been performed to propose mechanisms to identify debt and decide the most appropriate moment to pay it off. It is important to investigate the current state of the art in order to provide both researchers and practitioners with information that enables further research activities as well as technical debt management in practice. Objective: This paper has the following goals: to characterize the types of technical debt, identify indicators that can be used to find technical debt, identify management strategies, understand the maturity level of each proposal, and identify what visualization techniques have been proposed to support technical debt identification and management activities. Method: A systematic mapping study was performed based on a set of three research questions. In total, 100 studies, dated from 2010 to 2014, were evaluated. Results: We proposed an initial taxonomy of technical debt types, created a list of indicators that have been proposed to identify technical debt, identified the existing management strategies, and analyzed the current state of art on technical debt, identifying topics where new research efforts can be invested. Conclusion: The results of this mapping study can help to identify points that still require further investigation in technical debt research.

Context: The technical debt (TD) concept describes a tradeoff between short-term and long-term goals in software development. While it is highly useful as a metaphor, it has utility beyond the facilitation of discussion, to inspire a useful set of methods and tools that support the identification, measurement, monitoring, management, and payment of TD. Objective: This study focuses on the identification of TD. We evaluate human elicitation of TD and compare it to automated identification. Method: We asked a development team to identify TD items in artifacts from a software project on which they were working. We provided the participants with a TD template and a short questionnaire. In addition, we also collected the output of three tools to automatically identify TD and compared it to the results of human elicitation. Results: There is little overlap between the TD reported by different developers, so aggregation, rather than consensus, is an appropriate way to combine TD reported by multiple developers. The tools used are especially useful for identifying defect debt but cannot help in identifying many other types of debt, so involving humans in the identification process is necessary. Conclusion: We have conducted a case study that focuses on the practical identification of TD, one area that could be facilitated by tools and techniques. It contributes to the TD landscape, which depicts an understanding of relationships between different types of debt and how they are best discovered.

To date, several methods and tools for detecting source code and design anomalies have been developed. While each method focuses on identifying certain classes of source code anomalies that potentially relate to technical debt (TD), the overlaps and gaps among these classes and TD have not been rigorously demonstrated. We propose to construct a seminal technical debt landscape as a way to visualize and organize research on the subject.

Hasty software development can produce immediate implementations with source code unnecessarily complex and hardly readable. These small kinds of software decay generate a technical debt that could be big enough to seriously affect future maintenance activities. This work presents an analysis technique for identifying architectural technical debt related to non-uniformity of naming patterns; the technique is based on term frequency over package hierarchies. The proposal has been evaluated on projects of two popular organizations, Apache and Eclipse. The results have shown that most of the projects have frequent occurrences of the proposed naming patterns, and using a graph model and aggregated data could enable the elaboration of simple queries for debt identification. The technique has features that favor its applicability on emergent architectures and agile software development.

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.

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.

While attention to gender diversity in software development teams is growing, it is not yet known whether practitioners see gender diversity as useful to mitigate undesirable communication patterns. In our previous study, we found, through the application of statistical models, a strictly connection between gender diversity and communication patterns, for this reason, we asked practitioners their opinion through the administration of a survey. We observed that while practitioners do not seem to consider gender diversity as being useful in this context, those practitioners who tend to motivate their considerations with their own professional experience. Moreover, participants highlighted that beside technical expertise, good communication skills are fundamental for developers within a software team and need to be carefully checked during the hiring process.

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.

Ponderación de términos basada en nombres para repositorios de código fuente Resumen. En el área de IR (i.e.; Information Retrieval), encontrar la relevancia de un término en un documento juega un rol vital. Sin embargo, no se cuentan con propuestas prominentes que definan mecanismos de IR para repositorios de código fuente, considerando las particularidades de nombrado y organización que siguen éstos. Este trabajo presenta un esquema de ponderación de términos para repositorios de código fuente, el cual se basa en términos presentes en los nom-bres de archivos, y criterios de organización de directorios de código fuente. La propuesta fue evaluada sobre populares repositorios de código abierto obtenién-dose términos frecuentes para el esquema planteado. Los resultados muestran ocurrencias de términos que son de consideración. Palabras clave: Ponderación de términos, frecuencia de términos, análisis de código fuente. 1 Introducción En el área de Recuperación de Información (i.e.; IR, Information Retrieval), encontrar la relevancia de un término en un documento juega un rol vital [19], siendo los esque-mas de ponderación de términos, un componente clave para el área de IR [1] [16]. Es así que la frecuencia de los términos dentro de un documento, es habitualmente em-pleada para tareas típicas de recuperación sobre grandes colecciones de documentos [5], tanto en documentos de texto corto, así como en documentos de texto completos [8]. Se tienen diversas técnicas de ponderación de términos en la literatura [19], donde TFIDF (i.e.; Term Frequency-Inverse Document Frequency) es el esquema de pon-deración más utilizado en aplicaciones de IR sobre documentos de texto [1] [7] [19] [22]. Sin embargo, no se cuentan con propuestas prominentes que definan mecanismos de IR para repositorios de código fuente, considerando las particularidades de nom-brado y organización que siguen éstos, entre sus vastas colecciones de archivos. Durante la codificación de software, es de importancia emplear nombres de identifi-cadores que sean significativos [4], ello permite: facilitar el entendimiento del código [12], proporcionar contexto a las abstracciones en lenguajes de programación de alto nivel [12], atender la calidad del código [20]. En consecuencia, los desarrolladores em-plean esfuerzo y atención en la selección de nombres que sean significativos [2] [12], expresando, a menudo, conceptos en los nombres de archivos (e.g.; clases) [2]. Asi-mismo, en el desarrollo del software se pueden establecer convenciones de nombrado

Hasty software development can produce immediate implementations with source code unnecessarily complex and hardly readable. These small kinds of software decay generate a technical debt that could be big enough to seriously affect future maintenance activities. This work presents an analysis technique for identifying architectural technical debt related to non-uniformity of naming patterns; the technique is based on term frequency over package hierarchies. The proposal has been evaluated on projects of two popular organizations, Apache and Eclipse. The results have shown that most of the projects have frequent occurrences of the proposed naming patterns, and using a graph model and aggregated data could enable the elaboration of simple queries for debt identification. The technique has features that favor its applicability on emergent architectures and agile software development.