The Pandora's box of social, process, and people debts in software engineering

In software engineering, technical debt (TD) has been widely investigated, but debt regarding social issues, people, and processes has not been explored as much. It should be noted here that we use nontechnical debt (NTD) as an umbrella term to cover social, process, and people debts. Although the number of studies on NTD in software is increasing, the majority of them are descriptive rather than rigorous, and there is no systematic development of cumulative knowledge. As a result, identifying the fundamental causes of NTD and the associated mitigation techniques in software engineering is challenging. Therefore, this study investigates the scientific evidence regarding NTD till date by conducting a systematic mapping review of software engineering research between January 2000 and October 2021. The search strategy resulted in 175 studies, 17 of which were identified as unique and relevant primary papers. The primary studies show that NTD and TD are inextricably linked. In addition, this study also captured a plethora of causes and mitigation strategies for managing NTD and thus makes four important contributions: (i) highlighting state‐of‐the‐art NTD research; (ii) identification of the reported causes and mitigation strategies in the primary papers; and (iii) determination of opportunities for future NTD research.


| INTRODUCTION
Software companies have always striven to become more responsive in terms of identifying and satisfying customers' needs.One strategy for increasing responsiveness is the introduction of autonomous teams and agile software development. [1]Lean and agile methods have had a lot of success. [2]Specifically, these methods focus on swiftly responding to change, constant deliveries, individual interactions, customer collaboration, and so on.However, such a swiftly value-driven demanding environment is a breeding ground for suboptimal processes that might have shortterm benefits but an overall negative impact on the organization in the medium-long term.Examples of negative impacts can be duplicated work, misunderstandings, and integration problems.In this context, a financial metaphor can be used to successfully describe such phenomena: Aiming for short-term goals is equivalent to getting into debt, and the additional negative impact in the long term is considered as the interest that is paid.Whereas the term "debt" originated in the accounting domain and refers to a sum of money that is owed or due, [3] in software engineering, "technical debt" is used as a metaphor.
In 1992, Cunningham introduced technical debt (TD) to the software community as "the debt incurred through the speeding up of software project development which results in a number of deficiencies ending up in high maintenance overheads." [3]Avgeriou et al [4] further elaborated on this definition: "In software-intensive systems, technical debt is a collection of design or implementation constructs that are expedient in the short term, but set up a technical context that can make future changes more costly or impossible.Technical debt presents an actual or contingent liability whose impact is limited to internal system qualities, primarily maintainability and evolvability." [4] software engineering, this metaphor is used to describe prevalent issues including TD (i.e., code debt and smells) and other debt (i.e., process, social, and people debts). [5,6]Moreover, TD is no longer restricted to issues with source code and is now used to describe situations where developers make sacrifices in the development or take shortcuts in order to optimize other things, such as implementing necessary features before a deadline, [7] for example, "sneaking around an abstraction because it is too hard (or impossible) to figure how to 'do it right', skipping or scrimping on documentation (both in the code and external documentation)." [8]Further, its application has evolved and extended to other artefacts (e.g., design, testing, and documentation) of the entire software development life cycle. [7]Thus, TD is a critical issue in the software industry.Below, we have provided real-life examples of the significant costs incurred by TD.In 2010, Gartner estimated the global TD bill to be $US500 billion, with the potential to double in 5 years. [6]The CISQ 2020 report determined that the total cost of poor software quality in the US was $2.08 trillion, and TD resulting in the need for the correction of severe defect would need another $1.31 trillion (minus interest). [9]Meanwhile, in the case of the Danish government, a third of critical IT systems are in inadequate condition, for example, out-of-date or with non-existing documentation, lack IT security, and outdated software and hardware needs upgradation. [10]Regarding Sweden's government agencies, 70% of their IT systems were outdated. [11]wever, TD is only one side of the coin because software development is a sociotechnical phenomenon.Specifically, it is a structural barrier, [12] and management is responsible for decisions that cause it. [13]"In the sense, technical debt is incurred in one discipline, but it is burdened and has to be repaid in another discipline" [13] (p. 40).Further, according to Klinger et al, [14] "the decision to acquire technical debt is not made by technical architects, but rather by non-technical stakeholders who cause the project to acquire new technical debt or discover existing technical debt that wasn't previously visible" (p.35).In this context, Kruchten et al [15] explained that some aspects of TD are visible (i.e., new functionality to be added), whereas others are invisible (natural software ageing and evolution).Further, they elaborated that the major causes of TD are schedule pressure, carelessness, lack of education, poor processes, non-systematic verification of quality, or basic incompetence. [16,17]reover, software projects' success or failure is a combination of both technical and nontechnical aspects. [18,19]However, both researchers and practitioners paid a lot of attention to TD in comparison with other types of debt in software projects.Nevertheless, software development is a human-centered sociotechnical activity that has a symbiotic relationship with the environment and the way it operates as well as interlinked people or stakeholders.In this context, Appendix A offers a glossary of the 15 types of debt and their definitions.Some of them are purely technical, such as Defect TD, whereas others depend on a combination of social and technical aspects, such as requirements and design debts.The final three types of debt listed in Appendix A (process, social, and people debts) mainly cover nontechnical or social aspects of software development.In this paper, we use "nontechnical debt" (NTD) as an umbrella term to cover these three types.
In light of the existing literature, it is evident that during the last 10 years, TD has been heavily investigated to understand its functioning from various perspectives.For example, TD effort, [6] tools, [20] and types, management strategies [21] and managing architectural TD [22] as well as TD in terms of agile development, [23] management elements, [24] and prioritization, [5] etc.Meanwhile, NTD has remained latent and relatively unexplored.To better understand debt, there is a need for investigation to consolidate NTD literature in software engineering.To the best of our knowledge, no systematic mapping review has been conducted on NTD, which covers process, social, and people debts.
The overarching goal of this study is to identify and structure the body of knowledge of NTD in software engineering by conducting a systematic mapping review.The aims of this study are as follows: • Examine the latest research on selected NTD in software engineering

• Identify and analyze the causes of NTD, along with mitigation strategies
• Identify the opportunities for future research on NTD The rest of the paper is organized as follows.In Section 2, the process (e.g., planning, conducting, and reporting) of the systematic mapping review is presented.Then, in Section 3, we conduct a search for the latest and most relevant NTD research.Section 4 offers details of reported NTD definitions and causes with examples.Section 5 compiles a plethora of NTD mitigation strategies.Sections 6 and 7 provide a discussion of our results and future research direction, respectively.Finally, the validity threats and limitations of the study are discussed in Sections 8 and 9 to conclude the paper.This section presents the systematic mapping process.In this study, we follow the guidelines provided by Kitchenham et al [25] and Petersen et al, [26] which have three main phases: planning, conducting, and documenting.Each phase of the mapping study is discussed in detail in the rest of the section.

| Planning the mapping study
The impetus for conducting a systematic mapping study is to focus on the "classification and thematic analysis of literature on a software engineering topic" [11] (p. 640).In this context, Kitchenham et al [25] provided a detailed comparison between a systematic literature review and a systematic mapping study.A typical systematic literature review is motivated by a specific research topic that may be answered empirically.On the other hand, a mapping study examines a wider range of software engineering issues and categorizes the key research publications in a certain area. [25]The research topics in mapping studies are relatively intricate, such as those in which empirical methodologies were employed.Specifically, the motivation for conducting this mapping study is to identify, classify, and analyze the current state of NTD in the context of software engineering.To achieve this broad research objective, the research questions detailed in Table 1 will be answered.
As RQ1 is a broad research question, five sub-questions (RQ1.1-RQ1.5)have been identified as being pertinent to answering this question.
RQ2 and RQ3 will then provide a synthesis of the reported NTD causes as well as management strategies in the software engineering domain.
Next, RQ4 will identify potential research gaps in the context of NTD to guide future research initiatives.

| Conducting the mapping study
At first, we conducted a pilot search on debt in software engineering using Google Scholar.The aim was to determine the existence of any secondary studies on the given topic.We conducted this search using the following string: ("process debt" OR "social debt" OR "people debt" OR "technical debt") AND ("systematic mapping" OR "mapping study" OR "systematic literature review").The search was conducted in October 2021, and Google Scholar yielded 663 results.It was evident from the search that the current focus of research is predominantly on TD, whereas not a single review was found on NTD.Therefore, we conducted a systematic mapping review to explore and provide insight into NTD using the guidelines defined by Kitchenham et al [25] and Petersen et al. [26] The search string was formulated based on the population, intervention, comparison, and outcome (PICO) criteria suggested by Kitchenham and Charters. [27]Nevertheless, we relied on the population AND intervention combination while omitting the comparison and outcomes facets of PICO because our aim is to cover NTD, which is a broader research topic and avoid limiting the outcomes or comparing the interventions.Specifically, population refers to the application area that is software, and intervention refers to NTD (process, people, and social debts).The former is the expected search that will include all documents with the word "software" in the title, abstract, or keywords.It was executed in six databases: ACM Digital Library, IEEE Xplore Digital Library, ScienceDirect, Scopus, SpringerLink, and Web of Science.The selected databases are recognized and pertinent to this study, as these return the most publications in the software engineering domain. [27]The selected databases and retrieved papers are listed in Table 2.
In total, the search string used across six databases retrieved 175 publications.Two authors independently analyzed the 175 publications to remove the following: (i) duplicate papers; (ii) non-English publications; (iii) non-software engineering studies; and (iv) non-peer-reviewed scientific papers.Next, the authors conducted in-depth reviews of each paper; this required the researchers to read the titles, abstracts, introductions, and conclusions.The outcome of this process was 17 primary studies, which were then quality assessed using the 11-factor criteria proposed by Dybå and Dingsøyr. [28]The primary studies (S) are listed in Appendix B and are identified by the symbol (S).

| Inclusion and exclusion criteria
The inclusion and exclusion criteria in Table 3 were used to ensure the inclusion of relevant studies that are within the scope of this study and that address the research questions.In addition, the studies that presented empirical data were eligible for inclusion in this mapping review when there was clear evidence of research rigor.

| Identification of primary studies
Figure 1 illustrates the paper selection process used in this study.This process adopted the best practices proposed by Dybå and Dingsøyr [28] and Kitchenham et al. [25] First, we removed duplicates from the entire list of studies obtained from the aforementioned six databases.In total, 175 studies were obtained, of which 39 were duplicates.Each author then independently applied the inclusion and exclusion criteria.Two authors then discussed disagreements and jointly agreed on inclusion or exclusion decision.
In the second step, we applied the inclusion and exclusion criteria to the remaining 136 studies.Two authors read the titles, abstracts, and keywords of the remaining 136 studies and examined their relevance to this mapping review.In the case of an unclear paper, it was moved to the complete reading list for the next step.At the end of this activity, 76 studies out of 136 were included in the next step, which is a complete reading and on which the analysis is based.At the end of this activity, 57 papers were excluded, and 19 were selected for quality assessment.Subsequently, two researchers independently applied the quality assessment criteria.Two papers were excluded because they did not fulfil the assessment criteria.Finally, at the end of this step, we obtained 17 primary studies for this systematic mapping review.

| Data extraction and analysis
After careful selection, all primary studies were subjected to an in-depth analysis.We used the technique of researcher triangulation and the formulation of specific data extraction definitions to avoid researcher bias.All primary studies were evaluated for quality (e.g., research rigor and relevance) as well as study characteristics (e.g., study type, method, domain, pertinence, publication channel, etc.).Each primary study was individually examined by two researchers, who then integrated their peer-reviewed findings into the analysis and reporting of workshop settings.This method assisted us in discussing and resolving any disagreements.Finally, one author had a panoptic vision of the entire mapping study as well as each activity.It helped in ensuring the consistency of the analysis, consolidating results, and reporting.

| Quality assessment
To assess the quality of primary studies, we applied the 11-factor quality assessment criteria (see Table 4) proposed by Dybå and Dingsøyr. [28]ch of the criteria questions was graded on a 5-point Likert scale (where 0 = poor and 4 = excellent).This scaling strategy was adopted from Lenarduzzi et al. [5] Next, two researchers independently assessed the primary studies to limit the degree of subjectivity.A paper needed to achieve a rating of higher than or equal to "2" to be considered a primary study.The result is a more objective quality assessment of all primary studies, which is presented in the analysis section of the paper.

| RESULTS
The results and findings of the primary studies' analysis are presented according to the previously mentioned research questions (Section 2, Table 2).The findings in this section represent the current state of NTD research in software engineering.Specifically, Section 3 provides the The paper selection process following: (i) publication by year; (ii) publication channel; (iii) research method used; and (v) reporting quality assessment of primary papers.Subsequently, Section 4 provides NTD types, their definitions, and causes.In Section 5, each NTD type and its prevention strategy is presented, after which in Section 6, future research directions are listed.

| Publication by year
By analyzing NTD literature published between 2000 and 2021, we identified 17 primary studies (S#) based on our adopted selection process.
Figure 2 shows the number of primary studies per year.The publication trend provides a valuable insight into the fact that academic research on the topic is gaining momentum and the number of articles has been increasing in recent years.Based on our inclusion and exclusion criteria, we were not able to find empirical studies between 2000 and 2013.It is also evident that the majority of NTD studies have been undertaken in recent years (between 2019 and 2021).This is an indication that practitioners and academia are taking an interest in such topics due to the sociotechnical nature of software and systems development.

| Publication channel
The selected papers on NTD have been published in various peer-reviewed journals and international conferences.Table 5 shows the main peerreviewed publication channels for NTD research.In total, seven papers were published in journals, and 10 in international conferences.

| Research methods adopted in primary studies
We categorized the available literature on NTD according to the adopted research approaches.Table 6 offers a diverse picture of the research method used in our primary studies.Specifically, our mapping study focused only on empirical studies on NTD.A majority of the primary studies Is this a research paper?(or is it merely a "lessons learned" report based on expert opinion)

2.
Is there are a clear statement of the aims of the research?

3.
Is there an adequate description of the context in which the research was carried out?

4.
Was the research design appropriate to address the aims of the research?

5.
Was the recruitment strategy appropriate to the aims of the research?

6.
Was there a control group with which to compare treatments?

7.
Was the data collected in a way that addressed the research issue?

8.
Was the data analysis sufficiently rigorous?

9.
Has the relationship between researcher and participants been considered to an adequate degree? 10.
Is there a clear statement of findings? 11.
Is the study of value for research or practice?
Source: Dybå and Dingsøyr. [28]I G U R E 2 Publication by year adopted a mixed-method approach where data collection included surveys, semi-structured interviews, focus groups, workshops, observations, and document analyses.Meanwhile, only four studies adopted a qualitative research approach and conducted semi-structured interviews in single or multiple case studies.

| Quality assessment of primary papers
Here, we assess the quality of our primary studies using the 11-factor framework proposed by Dybå and Dingsøyr. [19]Two researchers independently assessed the 17 primary studies and discussed the disagreements in a workshop.The findings of our quality assessment discussion and comparison are aggregated in Table 7.
All of the selected primary studies describe their research aim and largely provide the necessary context of their studies.Among these, there was only one that ran an experiment, and it provided a detailed description of the study participants and compared the treatments where applicable.Additionally, all the studies also provided detailed information about "data collection."However, although the "data analysis" criteria were not fully reported in every primary study, we considered this to be adequate reporting.Further, the values and findings were reported in a clear manner in primary studies.On the other hand, the relationship between the investigators and participants is not clear in most cases.More specifically, four studies did not cover this issue anywhere in their respective articles.Overall, none of the primary studies received full points based on our quality assessment framework.Nevertheless, it should be noted that a majority of the primary studies are of high quality and are published in reputable scientific peer-reviewed publications.

| NTD TYPES, THEIR DEFINITIONS, AND CAUSES
This section presents the definitions of the three NTDs (i.e., process, people, and social debts) along with detailed descriptions of their causes in terms of software development.

| Process debt
Process debt is "a sub-optimal activity or process that might have short-term benefits but generates a negative impact in the medium-long term."S11 It also "refers to inefficient processes, e.g., what the process was designed to handle may be no longer appropriate." [29]rst, we will technically define process debt in the context of this paper.A process is a series of repetitive operations that must be completed to achieve specified organizational goals.For example, it is one that is used to implement a testing strategy.In this context, process debt can be referred to as inefficient processes and include situations in which what the process was designed to handle may be no longer appropriate. [29]milar to TD, process debt can provide short-term benefits but is generally detrimental to a software business in the longer run.An example here could be a team conducting daily stand-up meetings with a focus on updating the leader, where the short-term benefit is that the team satisfies leaders, but in the long run, the team circles around reporting and is not focused on sharing knowledge and solving dependencies.S11 Martini et al S4 investigated process debt for the first time and reported a number of its causes, a few mitigation techniques, and its subtypes as listed here: role related-mismatching roles and responsibilities; process related-documentation, synchronization, activity-specific, and infrastructure debts as well as process unsuitability.However, the results need to be taken with caution because existing literature on software process improvement and change management challenges has many similarities with the challenges of process debts.Overall, in this mapping study, the goal is to explore and map the existing literature on process debt in terms of understanding the phenomenon and its causes and effects.In this type of debt, there are two main actors (i.e., process designers and process executors) and four key accumulation patterns (i.e., suboptimal process design, process divergence, tools, and infrastructure deficiencies).S4 Table 8 summarizes process debt challenges and their causes.

| Organizational challenges
The organization itself is predominantly a major contributor to process debt, which has both short-term and long-term negative effects.In this context, Martini et al S4 highlighted that process sub-optimality can actually often lead to waste (of time, effort, budget, etc.) for stakeholders.For example, a company may change a process based on their financial estimates that later turn out to be incorrect and thus cause fear and extreme caution while handling process debt.S4 Furthermore, introducing new conflicting processes without careful planning generates a substantial overhead.This indicates that a lack of process competencies (which include design, management, and execution processes) is another source of debt.In addition, a lack of software culture is a major cause of process debt in an organization dealing with mechanical and electrical engineering as well as the development of other cyber-physical systems.There are two main reasons: First, a process design made for the mechanical and electrical engineering context might not be optimal for software development; second, individuals have different levels of experience, maturity, and motivation as well as leadership styles.S4 Regarding the second reason, one of the inferences of such challenges can be linked to a lack of coordination and engagement in the development of people in the organization.The experienced people might ignore or optimize some activities without following given guidelines, whereas those who are inexperienced follow a process too rigidly or lean toward excessive conformity to standards as they are confused.Thus, inter-team coordination is necessary when documentation and tools are used across teams.S11 According to literatures, S3, S5 the quality of the product suffers and process regresses when an organization focuses on producing more and ensuring that a product is put on the market faster.These aforementioned challenges are directly linked to the lack of a follow-up process assessment.Specifically, the negative effect here is that organizations are unable to identify and track possible challenges, and process divergence leads to the accumulation of process debt.Finally, business decisions generate pressure on the development team and affect the amount of debt, as explained in literature S16 : "Previous years' business decisions have affected us a lot.The reason for this that we have a release every two months and when we have a bigger release, we just do not have enough time to do it.This means that we are in a hurry at the end of release, and we have to just implement a faster solution.I think that the problem is that management is not willing to see what people are actually doing during the work day and how much time doing something is actually taking.This leads to problems in the distribution of resources, and I think that has been our problem these days."

| Process divergence
Process divergence is an umbrella term, and according to Martini et al, S4 "process designers create flawed processes, process executors diverge from well-designed processes, and the deficiencies of a supporting infrastructure might create difficulties."Thus, process divergence is not only itself a challenge, but it also leads to other issues such as not following standards in the highly regulated software domain, inappropriate planning and prioritization, and so on.The need for reworking, additional time, and concessions as well as drop in individual productivity all influence the quality of the software development process.S3 Specifically, by not adhering to coding standards, junior developers expose themselves to accidental debt accumulation.Further, when product code reviews are not executed regularly, as defined by the process, debt is accumulated by the inclusion of a bad solution.S16 In this context, process debt has both long-term and short-term consequences.In the long term, customer deliveries are delayed, software quality is poor, and other processes are impeded, whereas in the short-term, the immediate consequences are developer overload, errors, and a lowering of their morale (due to the tough job) as well as a lack of trust in the process.S4

| External dependencies
Formal ways of interacting with external parties, or a lack of them, might contribute to process debt.Yli-Huumo et al S16 explained the problems of not understanding customer expectations and thus not being able to build customer satisfaction.Besides a process to understand the expectations from specific customers, more are needed to understand the market.If not, a lack of knowledge about future changes could cause an increase in process debt.S16 Whereas a software development organization uses its own processes, other companies, units, teams, or special domains could all contribute to making existing processes suboptimal.S4 These special contexts and situations could generate process debt and have costly consequences if they are not accounted for in the process.S4 Moreover, both Martini et al S4 and Ramač et al S5 have noted the importance of infrastructure, in that technology and tools are important in terms of supporting the processes as well as automating and facilitating steps.More specifically, the inadequate choice of technology S5 or lack of infrastructure S4 could cause additional process debt, such as when an old configuration management tool does not support fast deliveries.In addition, external trends could also affect which processes are adopted in a company, and choosing those that are not suitable for the company can lead to process debt.S4

| People debt
People debt refers to issues with people that, if present in a software organization, can delay or hinder some development activities.An example of this kind of debt is too few people having the necessary expertise due to delayed training and/or hiring. [17]ople debt is a complex phenomenon focused on people-related issues with the close involvement of socio-organizational factors.The effect of this debt has a direct connection to productivity and people satisfaction.S3 Our analysis identified four main themes of challenges regarding people debt, and they are summarized in Table 9.

| Lack of knowledge and experience
The key factor in people debt is the individual knowledge in an organization.In this context, the selected primary studies reported knowledge in terms of different issues, such as people's insufficient knowledge about technology, lack of product and context knowledge, lack of technical competencies, and/or hiring irresponsible staff.More specifically, there are several factors contributing to a lack of product knowledge.For example, requirements from many different stakeholders (e.g., regulatory bodies) or rapid changes in technologies make it difficult to identify which features a product should have after several years of its development.S13 This lack of knowledge can lead to the requirements being considered vague or unclear.S13 Context knowledge is also a major issue in the embedded software area.For instance, original equipment manufacturers often do not provide all the details to protect their intellectual property.S13 Additionally, when teams use an iterative development approach and information is not shared appropriately, individuals are unable to see the overall picture due to only being given part of the overall requirements in each iteration.S13 Further, knowledge sharing is one of the key elements of social capital, as software development involves people inside and outside their teams.In this regard, Tamburri et al S10 noted that "in software engineering, cognitive distance can be thought of as the distance that developers perceive on the physical, technical, social and cultural level with respect to peers with considerable background differences." Along with knowledge discussed above, another important factor is hiring relevant and responsible people.More specifically, Mandi c et al S3 found that a case company "[lost] a client due to people-related issues" and elaborated as follows: "We spent a lot of time and money on irresponsible people, and because of that, the project was stopped.We looked too long at short-term earnings and survival, instead of the long-term cooperation and quality."According to Ramač et al, S5 lack of experience can lead to incurring debt and is likely to cause inappropriate planning, ill-defined processes, and ineffective project management.Further, new and junior coders accumulate unintentional debt mainly due to their lack of experience and are prone to cognitive distance.S16

| Lack of commitment
Regarding people debt, misconduct was reported as an issue in both Mandic et al S3 and Ramač et al.S5 Specifically, one type was hiring irresponsible people who lacked commitment to the project, whereas another was the presence of priggish members-those who make demands from others in an irritating manner.S3, S12 They might pointlessly demand precise conformity or exaggerated propriety in a self-righteous manner, in particular.
However, the software business requires a mindset of commitment towards innovation and being ready for change based on circumstances.Thus, people avoiding or refusing to work in a new way or consider innovative ideas is a sign of a lack of commitment.S5 Here, a classic example is being stuck with a waterfall model despite the need for agile methods or DevOps.teams are mostly male dominant, and women face several challenges, such as the lack of acceptance of women in software development teams, sexual and moral harassment, lack of equality and gender diversity, and sexist and gender-related jokes.Here, the lack of trust, equal treatment, and incentives demotivate women.The same study also highlighted that there is a lack of trust in women to accomplish some tasks: "the most boring activities are always assigned to women because usually the men team-mates do not want to execute them."S2 Further, management finds it more challenging to convince staff to have decent and neutral conversations among teams: "I had to adapt myself to the way the men talked, e.g., the slang and the bad words.When I arrived on the team, it was common for me to hear jokes from teammates that I was stupid because I am a woman."S2

| Morale
Morale is a multidimensional concept, which is defined by Peterson et al as follows: "[it is] a cognitive, emotional, and motivational stance toward the goals and tasks of a group.It subsumes confidence, optimism, enthusiasm, and loyalty as well as a sense of common purpose."Software development is a very complex process, and in today's world, it demands that developers understand their feelings and perceptions as well as the motivational factors in their environment.Specifically, there is a connection between developers' productivity and software quality and their satisfaction, happiness, and motivation.S7 Additionally, software professionals' morale is affected by various factors such as the development process, quality of the overall software product, architecture, etc. S7 In this context, TD harms morale, because developers see it as a roadblock to development and find that it makes it difficult for them to complete their tasks.On the other hand, TD management boosts employee morale.The key reason is that it is linked to positive personal and interpersonal feedback, which allows developers to perform their tasks in a better manner and increase software quality in the future.S7 Dreesen et al S8 also highlighted that psychological safety plays an important role in software development, as the lack of it contributes to various types of debt collection, such as social debt.S8

| Social debt
Social debt is analogous to technical debt in many ways: It represents the state of software development organizations as the result of "accumulated" decisions.In the case of social debt, decisions are about people and their interactions.S17 Tamburri et al s7, s8, s19, s23, s29 were the first to extensively investigate social elements of debt under the term "social debt" in software development.First, it should be noted that software development is a sociotechnical process.Thus, social debt is closely linked to TD, as, for example, uninformed sociotechnical decisions compound both social and technical debts that cannot be "paid back" easily.S17 Second, social debt involves people as well as their interactions and related decisions.Third, awareness maintenance methods are conceptually similar to the concept of social debt, because they track and preserve project knowledge to reduce delays and associated debt.S17 Fourth, social debt is a cumulative and increasing cost in the current state of things, connected to invisible and negative effects within a development community.S17 Thus, it easily emerges in the scaling of agile methods or offshoring, and sociotechnical congruence is the first rudimental sign of the same.S17 In this context, Tamburri et al S17 presented numerous aspects of social debt, such as how it is indirectly related to socio-technical decisions and how it is an emerging attribute of the development community.Several triggers result in the creation of social debt, such as omissions, compromises, bad behavior, not seeking or giving help to colleagues, power distance, gender bias, etc. S2, S8 The complete list of causes of this debt is provided in Table 10.

| Gender challenges
In general, the presence of female workers in the software business is unbalanced, as compared with men, fewer women work in the information and communication industry.The issue of gender is Pandora's box, but in this paper, we only focus on it in the context of software development teams and their connections to social debt.The existing literature has highlighted that gender-diverse organizations have higher levels of innovation, problem-solving skills, and a healthier work environment.S2 However, Canedo et al S2 reported several issues, for example, the lack of trust in women's competencies and capabilities as well as equal treatment and communication, harassment, etc. Men are also likelier to hold technical leadership positions in software development teams.In this context, the lack of trust can be better expressed using this example: "the most boring activities are always assigned to women because usually the men team-mates do not want to execute them."S2 Further, compared with men, women are treated differently in teams: "when the team is assembled by a woman, the team behaves differently.Also, one woman in a leadership position sometimes still causes strangeness in other teams."S2 Moreover, the most recurring barrier is related to the lack of gender-equal communication, as some men do not talk equally to their female teammates.In order to express an opinion, women need to interrupt men's speech; this happens even if the person who wants to talk is a female project manager.S2 One interviewee also reported that the following: "I had to adapt myself to the way the men talked, e.g., the slang and the bad words.When I arrived on the team, it was common for me to hear jokes from teammates that I was stupid, because I am a woman."S2

| Challenges in communication, collaboration, and coordination
Communication, collaboration, and coordination are sometimes referred to as the 3Cs.S8 First, in terms of communication, social debt can occur due to omissions, compromises, or bad behavior.S5, S8, S11 Moreover, the concept of this form of debt shares some similarities with that of social capital, which refers to resources within and derived from social relationships among actors.S8 Building social capital can be seen as a process of building attributes such as trust, relationships, and a shared understanding.A related concept is psychological safety, which refers to the perceived climate and the perception's effect on the actors' resulting behavior.S8 The two concepts of social capital and psychological safety are interconnected, but they consider different aspects: the former is focused on individual actors and their place within the social network, whereas the latter is more concerned with the perceptions of the team.S8 In the context of this paper, if developers use their social capital to force omissions in the general communication patterns or to coerce compromises, the results may lead to social debt and undermine the positive influences that enabled the building of the capital in the first place.S8 For example, a lack of communication depth could be due to remote communication in which gestures and physical features cannot be seen or are not as prominent.S8 Another possible problem due to digital meetings could be a lack of communication latency because of slower or staggered communication.S8 Besides meetings, the lack of informal communication, such as non-structured, ad hoc talks, could add to social debt.S8 Less spontaneous visits to colleagues' offices or canteens are also examples of a lack of unintentional communication.S8 In addition, the lack of feedback loops could mean less or missing business-related information, and the consequent misinterpretations could also lead to a lack of shared understanding.S8 Second, collaboration challenges are also possible reasons for the building up of social debt.S5, S8 Here, a lack of conflict resolution could occur, sometimes unintentionally, if conflicts are less frequently addressed or resolved.S8 In an environment with a need for highly task-oriented interactions, the intensity of task-related collaboration could be a possible problem.S8 However, according to a study by Dreesen et al, S8 the aforementioned intensity was the only investigated factor that had both a promoting and mitigating effect on social debt.Additionally, if the availability of team members is not transparent and/or synchronized regularly, there could be a problem in terms of the lack of consistency in employee availability.S8 In situations where knowledge transfer is reduced or postponed S8 or documentation is lacking, S5 a lack of knowledge transfer capabilities could also cause issues.
Finally, coordination entails several factors that possibly cause social debt.S5, S8, S11 When rules and schedules for teamwork have not been set up (e.g., deciding on and sticking to core working hours) or are loosened, there is a lack of coordinative mechanisms.If the behavior of team members cannot be observed and the desired conduct cannot be identified-for example, if the team is not collocated-the lack of formal control could cause problems.However, a lack of informal control could also cause problems if values and norms that promote teamwork are not in line with a company's goals.S8 One example of such values and norms could be, as Martini et al S11 pointed out, a lack of team autonomy if the company does not allow a mandate for making decisions.Moreover, if common leadership tasks are neglected, such as inspiring, encouraging, and supporting the team S8 or inappropriate planning, S5 the lack of leadership could increase social debt.Further, if the behaviors of individuals or teams are unclear or missing, there can also be a lack of transparency.S8

| Community smells
The sum of negative and unforeseen costs/consequences given by suboptimal social relations among developers has been named "community smells."S9 According to Catolino et al, S9 these smells represent one of the main causes of social debt and, as such, threaten the entire management of software systems, because they may substantially decrease the level of trust within a community.
There is the first type of community smell, called hyper-community, S10 which refers to a community where decisions are made based on groupthink and are thus biased and could cause social debt.Such a hyper-community could, in turn, also influence other subcommunities in its fold.S10 The second smell, called power distance, takes place when less powerful or responsible members of a software development community perceive, accept, and/or expect a distance from powerholders.S10 If there is a presence of siloed areas of the developer community that do not communicate with the rest of the community, except through one or two of their respective members, it is a sign of what is called the "organizational silo effect."S9, S17 Signs of this smell include the high decoupling between tasks and a lack of communication.S17 Meanwhile, information overload due to a lack of structured communications or cooperation governance is a smell caused by the "black cloud effect," S9, S17 which is defined as a lack of boundary spanners and a proper sharing of initiatives and protocols.S17 Additionally, another smell, called the "lone wolf effect," S9, S6 could also appear when the development community has unsanctioned or defiant contributors who carry out their work with little consideration for their peers, decisions, and communication.An example of this smell is when non-architects are forced to make decisions because actual architects are "too few and far apart."S6 When a highly formal and complex organizational structure full of "regular procedures" forces changes to be slowed down and consequently loses time between hierarchical people, S17 the smell is called the "radio silence effect."S9, S17 A sign of this smell is that one member interposes himself/herself into every formal interaction across two or more subcommunities with little or no flexibility to introduce other parallel channels.S9

| PREVENTION STRATEGIES FOR NTD
This section presents prevention strategies and actions to mitigate the three types of NTD (i.e., process, people, and social debts).

| Prevention of process debt
Regarding organizational challenges, Tamburri et al S12 investigated architecture issues causing process debt and presented a prevention strategy called the "Dev-Ops shift-left."This shift is explained as moving the development-to-operations team to an earlier ("left") position in the development life cycle, which involves architecture and development, and thus having operations staff also work as developers.These authors also suggested as prevention strategies as follows: designing a people-oriented rather than feature-oriented architecture and a model-based mediation of knowledge and keeping track of actions, agreements, and expectations through work-division artefacts.S12 Meanwhile, to prevent a mismatch between requirements at different abstraction levels, Liebel et al S13 suggested documenting decision rationales-that is, the why and how a requirement should be broken down to a more detailed level.Additionally, Freire et al S1 presented five strategies to prevent process divergence in agile, hybrid, or traditional software engineering: following a well-defined project process, adhering to project planning, refactoring, performing risk and impact analysis, and having well-defined requirements.The authors went on to suggest two criteria for choosing a prevention strategy: (i) consider the most commonly used preventive actions as a starting point and (ii) combine preventive actions based on debt types.Finally, Yli-Huumo et al S16 suggested the creation of coding standards and guides as well as improving the communication structure between business management and development teams.
Table 11 shows a summary of prevention strategies to mitigate process debt for a few of the identified causes of organizational challenges and process divergence, as none of the papers have suggested strategies to manage external dependencies.

| Prevention of people debt
For the category called the "lack of knowledge and experience," Liebel et al S13 suggested the use of graphical models as "thinking tools" to overcome the inadequacy of product knowledge.Regarding the lack of context knowledge, these authors suggested increased traceability between requirements.In particular, if a clear link is provided to a higher level of abstraction, it is possible for developers to better understand the context.S13 Meanwhile, Freire et al S1 proposed the improvement of technical knowledge by training and good communication to build an effective team.As onboarding of new employees is important and to ensure that the problems of "newbie free-riding" are mitigated, Tamburri et al S12 suggested several preventive actions, one of which is called "mood polling."This entails sharing your mood as a team member regarding the organizational scenario and its mapping onto architecture elements.By investigating reported "bad moods," developers are consequently empowered to deal with architectural problems.Further, Tamburri et al S12 explained that harmonizing responsibilities by implementing roles and practices from Scrum or other agile frameworks could minimize problems with priggish members.However, regarding inadequate management decisions, only a prevention strategy concerning the lack of gender equality has been addressed in the literature.Specifically, Canedo et al S2 proposed programs to promote gender diversity by using campaigns and/or lectures on the importance of having gender diversity, hiring more women, giving more opportunities to women, and increasing women's representation in the organization.
Table 12 shows a summary of prevention strategies to mitigate people debt for a few of the identified causes on the lack of knowledge and experience as well as commitment and inadequate management decisions.This is because none of the papers have suggested prevention strategies to manage morale issues.

| Prevention of social debt
Canedo et al S2 suggested gender diversity programs, as noted above, to mitigate the lack of gender diversity and also to prevent gender challenges.Besides the areas covered above, these gender diversity programs should include policies against harassment and define those for the inclusion of women as well as allow for the sharing of experiences and the curbing of sexist attitudes.S2 Additionally, Dreseen et al S8 presented a prevention strategy containing four intertwined preventive actions to manage the lack of communication and collaboration.They explained that "honest and open communication" along with "reduced upfront costs for initializing interaction and communication" contribute to an environment in which social conflicts may be addressed and solved more easily; therefore, social debt can be decreased.They also found that the action of "improving psychological safety" had a mitigating effect on both lack of communication and collaboration.Meanwhile, the "intensity of task-related collaborations" had both a promoting and mitigating effect.S8 Overall, most of the prevention strategies put forward in the reviewed primary studies focus on mitigating community smells.In terms of hyper-community smells, where groupthink could cause social debt, Tamburri et al S12  and (vi) introduce a social-rewarding mechanism.For the organizational silo smells, Tamburri et al S17 suggested adopting a "social wiki" where practitioners' profiles are combined with the artefacts under their care and the connected documentation, whereas for the radio silence smells, they suggested establishing an online learning community as a prevention strategy.
Meanwhile, Catolino et al S9 suggested three strategies to mitigate the black cloud smell, due to which information overload could cause social debt.However, these suggestions have already been proposed to manage the previously mentioned organizational silo smell: restructure the community, create a communication plan, and introduce a social-rewarding mechanism.Regarding this smell as well, Tamburri et al S17 again suggested adopting a "social wiki" as a prevention strategy.Finally, Catolino et al S9 suggested five strategies to mitigate the lone wolf smell, due to which defiant contributors who carry out their work with little consideration for their peers could cause social debt.These strategies are all the same as those suggested to prevent organizational silo smells except for "create a communication plan."Here, Tamburri et al S6 suggested the use of architecture boards consisting of software architects and other interested parties to mitigate the lone wolf smells.
Table 13 shows a summary of prevention strategies to mitigate social debt.Several prevention strategies that have been explained are proposed for community smells, but there are only a few suggestions to mitigate gender challenges and 3C challenges.

| DIRECTIONS FOR FUTURE RESEARCH
The focus of this mapping review was to provide an overview of what has been investigated regarding NTD in scientific literature.We found that most of the research focuses on TD and less attention has been paid to NTD.However, it should be noted that NTD are factors that contribute to TD.This means that the latter is not always based on technical aspects and might be caused by other factors such as various stakeholders, adopted processes, and social and cultural relatedness, which are less investigated in this context.In light of our analysis and synthesis of the previously identified primary studies, the following governing questions should be examined and researched in the future: • Are software professionals familiar with the concept of NTD?
• What similarities and differences exist between TD and NTD?
• Is there any connection between sustainability debt and NTD?
• What are the factors that affect process, social, and people debts during the software life cycle?Are there patterns in the behaviors of such factors?
• What effects do NTD have on software projects?
• What types of events characterize the causes and effects of process, social, and people debts?
• How do process, social, and people debts originate and evolve in software development settings?
• What are the drivers of NTD in large-scale distributed agile software development teams?
• What are the factors mitigating the build-up of NTD in large-scale distributed agile software development teams?
• What types of NTD are elicited and discussed at the team and inter-team levels in large-scale agile software development teams?
• How do process, social, and people debts affect teamwork in software development teams?
• To what extent do process, social, and people debts represent threats to team cooperation?
• To what extent do practitioners (or managers) allow for the existence of NTDs that affect cooperation in their organizations?
• Is there any connection between interdisciplinary requirement engineering and NTD accumulation?
• Does organizational structure have any effect on NTD accumulation?
• Does a well-defined process and planning prevent process debt in both collocated and distributed large-scale agile software development projects?
• Does the pressure of deadlines contribute to NTD?
• What are the effects of business decisions on NTD?
• Does the communication structure between business management and the development team have an impact on NTD accumulation?
• Does gender imbalance in teams have any effect on NTD accumulation in software projects?
• Does the occurrence of NTD influence professional morale in the software industry?
• How do social elements (e.g., personal traits, self-efficacy, social identity, social ties, and inter-and intra-team interaction) play a role in NTD accumulation?
• How does NTD influence developers' psychological and motivational states in terms of their software development?
• To what extent can social and people debts affect the enforcement of the ACM code of ethics and professional conduct?
• What are the potential ethical and moral issues that software engineering professionals may face due to social and people debts?What is the knowledge-building role of the leader in NTD accumulation or management?
• What are the strategies applied by practitioners to deal with the causes of process, social, and people debts?
• How do stakeholders influence NTD and its management in organizations?
Thus, as seen above, there are many open research questions.However, it is unclear as to what types of mitigation strategies are necessary to handle NTD throughout an organization and what strategies have to be adopted.Moreover, because the new normal caused by the COVID-19 pandemic has been causing significant changes in numerous software and services businesses, it is worthwhile to investigate work satisfaction and NTD in both co-located and large-scale agile software development projects.It would also be interesting to investigate NTD under the lens of established theories such as the social capital, psychological safety, or control theories as well as communication, collaboration, and cooperation challenges in connection with the media naturalness theory.Additionally, Liebel et al S13 presented a three-point agenda for future debt research: (i) the need for a process that allows for sufficient levels of uncertainty during early requirement engineering; (ii) the need for an organizational structure that effectively supports interdisciplinary requirement engineering while taking the central role of software into consideration; and (iii) the need for concepts as well as organizational structures that allow for and support the management of "requirements debt."Further, in terms of software processes, the value for stakeholders is always considered, as ill-designed ones diverge from those that are well designed, and the lack of a supporting environment results in waste.These phenomena require investigations of their own.

| DISCUSSION
The topic of debt is relatively new as compared with other domains, such as software quality and testing.However, although there are significant studies published on TD, NTD has remained less explored.Among the different types of debt proposed in the work by Lenarduzzi et al, [5] we chose to investigate three types of debt under the umbrella of NTD: process, people, and social debts.In this study, we then adopted a systematic mapping review approach to identify, classify, and analyze 175 studies on NTD published between 2000 and 2021 in the field of software engineering.Of these, 17 articles were identified as primary studies, which were chosen based on the selection criteria defined for this review: those with acceptable academic rigor, credibility, and relevance.
Overall, we found that in recent years, there has been an increase in studies in the NTD research area.Moreover, the primary studies predominantly used a mixed-method approach (n = 9), whereas qualitative (n = 4) and quantitative (n = 4) approaches were adopted in four papers each.The mixed-method approach is interesting and able to offer valuable insight, but the progression of the used case studies was not explicit (e.g., when and how NTD emerged and had its effects).Further, as the NTD research area is still in its infancy, this mapping study did not find any longitudinal studies on this topic.However, the realities of NTD have been reported as anecdotal evidence.In terms of defining various forms of NTD, such as social, process, and people debts, this mapping study identified a lack of cohesion.This raises the concern that in the long term, NTD in software engineering could lack the cumulative building of knowledge or that there will be "fragmented adhocracy." NTD has a similar analogy to TD in terms of principles and interest.More specifically, the process debt metaphor supports the prioritization of process improvements.Examples of process debt are insufficient processes and documentation, inadequate software engineering practices, tools and planning, etc.This can be implied, as managing process debt contributes to the management of TD.In addition, there are techniques to help prioritize the aforementioned debt over other competing activities such as features, bug fixing, TD refactoring, etc.Such strategies are appealing, but they require adaptation and research to confirm or demonstrate their application in various contexts.
In terms of software processes, the value for stakeholders is always considered, and ill-designed ones diverge from those that are well designed, and the lack of a supporting environment results in waste.Overall, there are three main patterns in the occurrence of process debt: bad or flawed process design, divergence from a well-designed process, and lack of supporting infrastructure.In the case of process debt assessment, it is important to take the value of different stakeholders into consideration and pay attention to the process design.An ill-designed process leads to initiation waste and has long-term negative effects, such as the costs of making changes.Moreover, in the process debt, people are a crucial factor.The exploration of process competencies is critical in projects where software engineering teams work closely with mechanical and electrical engineers.More specifically, software and hardware engineers have different vocabularies, making it difficult to communicate with each another and causing problems in cross-functional teams.This is because processes that work well in one domain or context may not work well in another.In this context, the systematic research of metrics reflecting software processes and examining product characteristics across a wider range of situations (e.g., in industrial as well as hybrid open-/closed-sources) would be valuable.According to Freire et al, S1 following a welldefined project process and plan prevents process debt.However, it requires investigations of both collocated and distributed large-scale agile software development projects.Nevertheless, introducing such processes in a system engineering context is not easy due to the lack of interdisciplinary understanding.This is another avenue for people and social debt-related research, under one umbrella, on how teamwork can be harmonized and how people from two different domains can be better understood as well as communicate with each other.
Meanwhile, people debt is more related to people-centric issues such as the lack of specific skills and knowledge among workers, hiring of irresponsible staff, and unclear quality-related roles and responsibilities as well as workers' psychological aspects, morale, and emotions.Moreover, people debt has a direct connection to TD and affects individual productivity and satisfaction.Specifically, developers' morale and productivity go down with TD, which further hinders individual performances, motivation, progress, and the achievement of their goals.S4, S15, S16 In addition, women face gender bias in software development teams, as highlighted by Canedo et al, S2 as well as impediments such as a lack of trust, credibility, confidence, and recognition.Team cohesion is harmed by such biases, which can lead to the buildup of various types of debt.To confirm and augment these findings, gender imbalance in software development teams should be investigated in other cultures as well.Thus, future studies in this area may help software development teams to reduce social and people debt.
The lack of qualified professionals and the hiring of irresponsible staff are contributors to short-and long-term debt in software projects.
Meanwhile, in social debt, the decisions are more about people and their interactions, which are intertwined with TD.This indicates that bad sociotechnical decisions generate both technical and social debts.An example of such a decision would be the incremental contrariness of the addition of "technical experts" to teams in the development community or that of consultants to help with product renewal.Further, the causes of social debt have similarities with that of the 3C model of communication, the activities of which are crucial for software production and related operational activities.Specifically, communication is critical to the realization of organizational activities and the understanding of tasks, the coordination of activities with different stakeholders contributes to the efficient achievement of business goals, and cooperation on given tasks is necessary to handle concurrent and shared expertise.Naturally, various challenges arise in software development teamwork due to hindrances in communication and the lack of cooperation and coordination.However, to minimize social issues, organizations need to undertake trial-and-error exercises.Additionally, it is also evident that NTD and TD go hand in hand.Thus, we urge practitioners to pay attention to NTD as much as other types of TD.
Through this study, we have identified several preventative strategies and actions suggested for mitigating NTD, but they are few in number as compared with the identified causes and consequences.For process debt, prevention strategies are only suggested for a few of the identified causes of organizational challenges and process divergence.Moreover, none of the examined studies suggested prevention strategies to manage external dependencies.In investigating people debt prevention, we found only a few preventative measures targeting the identified causes of the lack of knowledge, experience, and commitment as well as inadequate management decisions.Here, none of the selected papers suggested prevention strategies to manage morale issues.In preventing or mitigating social debt, several strategies were proposed to manage community smells, but only a few were proposed to mitigate gender and 3C challenges.Meanwhile, Eduardo summarized and highlighted the frameworks (i.e., CAFFEA framework, architectural tactics, and DAHLIA) and tools (GEEZMO, CodeFace4Smell, YOSHI) that can be used to handle social debt. [30]This mapping of causes and prevention strategies displays the underdeveloped state of NTD research, as the few suggested prevention strategies have not been tested or evaluated in any scientific sense.

T A B L E 5
Primary studies by target journal and conference

T A B L E 1 1
Process debt prevention strategies Process debt theme Process debt causes mitigate Preventive actions Source Organizational challenges Lack of engagement in development A DevOps shift-left approach to address issues earlier during development and having operations staff also be developers S12 Designing a people-oriented rather than feature-oriented architecture Business decisions Communication structure between business management and development team S16 A mismatch between requirements on different abstraction levels Document decision rationales (why and how a requirement was broken down to a more detailed level) S13 Excessive conformity to standards Open communication and informality and model-based mediation of knowledge S12 Lack of innovation Daily stand-ups, and keeping track of actions, agreements, and expectations through work- T A B L E 2 Selected databases and retrieved papers proposed an architect-as-coach initiative where architects incite doubt through discussion and reverse logic.Next, Catolino et alS9proposed six strategies to mitigate organizational silo smells, due to which siloed areas of the developer community do not communicate, as well as radio silence smells, where delays in information sharing could cause 1 2 People debt prevention strategies