Who should pay for technical debt? Exploring software professionals perceptions about technical debt accountability

Context: Technical debt (TD) can compromise the quality of software systems in the long term. However, depending on the needs and properties of the specific product, different quality characteristics may be considered in the assessment with different levels of relevance. In this way, quality characteristics can guide teams in managing the TD, from identifying to paying for the TD items relevant to each situation. Although a set of TD item indicators has been identified in the literature, there is no clear guidance on how these indicators can be efficiently used to identify TD items. Aims: To investigate, from the point of view of software professionals using the SO platform, the relationship between the TD item indicators and the quality characteristics of the system, in order to guide the use of indicators for greater efficiency and effectiveness in identifying and managing DT items from a quality perspective. Method: We extracted empirical evidence using data mining from discussions related to TD on the SO. From the execution of an analysis process, the quality characteristics related to the occurrence of DT items identified in the discussions, the respective indicators and types of debt were identified. Results: The main results reveal that maintainability is the characteristic most related to TD through its sub-characteristics: modifiability, testability and modularity. Code debt items can be related to all quality characteristics, while Infrastructure debt can resonate up to 6 characteristics. All quality characteristics have at least one associated indicator, with an emphasis on Maintainability with 13 high-level and 28 low-level indicators. The indicator related to version problems is the one with the highest number of quality features. Conclusion: The relationship between indicators, TD types and quality characteristics was organized in a conceptual diagram in order to assist software teams in identifying which TD items are related to the quality characteristics that are critical to the project context, contributing to decision making regarding the best strategy for debt management.

This teaching case provides a simple yet comprehensive overview of Technical Debt (TD) and its associated terminology to the readers. TD, which has received an increasing amount of attention from information systems (IS) development research and practice, is mainly used to communicate the consequences of sub-optimal design decisions and trade-offs made during software development with non-technical project stakeholders. We reviewed the extant literature and interviewed five software professionals from a European company to examine this costly phenomenon. As such, we provide a comprehensive understanding of TD, its relevant terminology, and concrete examples that can help information systems and business students better understand the topic. In addition, the teaching case demonstrates antecedents, benefits and challenges, and the responsibilities associated with the accumulation of TD. We argue that, unfortunately, the moral responsibility associated with TD tends to get diffused leading to the invisibility of consequences and de-individuation issues in software teams. To this end, considering the critical role of software-intensive systems in modern societies, we argue that practitioners should look beyond the financial or technical costs and benefits of TD and consider the ethical and societal responsibilities associated with its accumulation carefully.

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

Context. Technical debt (TD) monitoring allows software professionals to track the evolution of debt incurred in their projects. The technical literature has listed several practices used in the software industry to monitor indebtedness. However, there is limited evidence on the use and on the reasons to avoid using these practices. Aims. This work aims to investigate, from the point of view of software practitioners, the practices used for monitoring TD items, and the practice avoidance reasons (PARs) curbing the monitoring of TD items. Method. We analyze quantitatively and qualitatively a set of 653 answers collected with a family of industrial surveys distributed in six countries. Results. Practitioners are prone to monitor TD items, revealing 46 practices for monitoring the debt and 35 PARs for explaining TD non-monitoring. Both practices and PARs are strongly associated with planning and management issues. The study also shows the relationship found among practices, PARs and types of debt and presents a conceptual map that relates practices and PARs with their categories. Conclusion. The results of this study add to a practitioners’ capability to monitor TD items by revealing the monitoring practices, PARs and their relationship with different TD types.

While Microservices promise several beneficial characteristics for sustainable long-term software evolution, little empirical research covers what concrete activities industry applies for the evolvability assurance of Microservices and how technical debt is handled in such systems. Since insights into the current state of practice are very important for researchers, we performed a qualitative interview study to explore applied evolvability assurance processes, the usage of tools, metrics, and patterns, as well as participants' reflections on the topic. In 17 semi-structured interviews, we discussed 14 different Microservice-based systems with software professionals from 10 companies and how the sustainable evolution of these systems was ensured. Interview transcripts were analyzed with a detailed coding system and the constant comparison method. We found that especially systems for external customers relied on central governance for the assurance. Participants saw guidelines like architectural principles as important to ensure a base consistency for evolvability. Interviewees also valued manual activities like code review or boy scouting, even though automation and tool support was described as very important. Source code quality was the primary target for the usage of tools and metrics. Despite most reported issues being related to Architectural Technical Debt (ATD), our participants did not apply any architectural or service-oriented tools and metrics. While participants generally saw their Microservices as evolvable, service cutting and finding an appropriate service granularity with low coupling and high cohesion were reported as challenging. Future Microservices research in the areas of evolution and technical debt should take these findings and industry sentiments into account.

The negative consequences of Technical Debt is an area of increasing interest, and more specifically the Architectural aspects of it have received increased attention in the last few years. Besides the negative effects of Architectural Technical Debt on the overall software product quality in terms of hindering evolution and causing high maintenance costs, Architectural Technical Debt also has a significant negative impact on software practitioners' daily work. Although a great deal of theoretical work on Architectural Technical Debt has been undertaken, there is a lack of empirical studies that examine the negative effects of Architectural Technical Debt during the software development lifecycle. The aim of this study is to investigate how practitioners perceive and estimate the impact of Architectural Technical Debt during the software development process. This paper reports the results of an online web survey providing quantitative data from 258 participants. The contribution of this paper is threefold: First, it shows that practitioners experience that the Architectural type of Technical Debt has the highest negative impact on daily software development work. Secondly, we provide evidence that does not support the commonly held belief that Architectural Technical Debt increases with the age of the software. Thirdly, we show that despite different responsibilities and working tasks of software professionals, Architectural Technical Debt negatively affects all roles without any significant difference between the roles.

ContextMicroservices as a lightweight and decentralized architectural style with fine-grained services promise several beneficial characteristics for sustainable long-term software evolution. Success stories from early adopters like Netflix, Amazon, or Spotify have demonstrated that it is possible to achieve a high degree of flexibility and evolvability with these systems. However, the described advantageous characteristics offer no concrete guidance and little is known about evolvability assurance processes for microservices in industry as well as challenges in this area. Insights into the current state of practice are a very important prerequisite for relevant research in this field.ObjectiveWe therefore wanted to explore how practitioners structure the evolvability assurance processes for microservices, what tools, metrics, and patterns they use, and what challenges they perceive for the evolvability of their systems.MethodWe first conducted 17 semi-structured interviews and discussed 14 different microservice-based systems and their assurance processes with software professionals from 10 companies. Afterwards, we performed a systematic grey literature review (GLR) and used the created interview coding system to analyze 295 practitioner online resources.ResultsThe combined analysis revealed the importance of finding a sensible balance between decentralization and standardization. Guidelines like architectural principles were seen as valuable to ensure a base consistency for evolvability and specialized test automation was a prevalent theme. Source code quality was the primary target for the usage of tools and metrics for our interview participants, while testing tools and productivity metrics were the focus of our GLR resources. In both studies, practitioners did not mention architectural or service-oriented tools and metrics, even though the most crucial challenges like Service Cutting or Microservices Integration were of an architectural nature.ConclusionsPractitioners relied on guidelines, standardization, or patterns like Event-Driven Messaging to partially address some reported evolvability challenges. However, specialized techniques, tools, and metrics are needed to support industry with the continuous evaluation of service granularity and dependencies. Future microservices research in the areas of maintenance, evolution, and technical debt should take our findings and the reported industry sentiments into account.

Technical Debt in Brazilian Software Startups: Perceptions of Professionals in Paraná

Maintainability assurance techniques are used to control this quality attribute and limit the accumulation of potentially unknown technical debt. Since the industry state of practice and especially the handling of Service- and Microservice-Based Systems in this regard are not well covered in scientific literature, we created a survey to gather evidence for a) used processes, tools, and metrics in the industry, b) maintainability-related treatment of systems based on service-orientation, and c) influences on developer satisfaction w.r.t. maintainability. 60 software professionals responded to our online questionnaire. The results indicate that using explicit and systematic techniques has benefits for maintainability. The more sophisticated the applied methods the more satisfied participants were with the maintainability of their software while no link to a hindrance in productivity could be established. Other important findings were the absence of architecture-level evolvability control mechanisms as well as a significant neglect of service-oriented particularities for quality assurance. The results suggest that industry has to improve its quality control in these regards to avoid problems with long-living service-based software systems.

This study aims to investigate the perceptions of software professionals in relation with impact of agile practices to accelerate the delivery of software products. Quantitative data obtained from a sample of 109 professionals were collected and analyzed by Pearson correlation and factor analysis. The results of factor analysis showed that the perception of professionals in relation to agile practices can be grouped into seven factors. From the correlation analysis, it was observed that customer satisfaction is the main variable influencing the perceptions of professionals regarding the use of agile practices to meet the deadlines on software projects.

Despite years of research for improving accuracy, software practitioners still face software estimation difficulties. Expert judgment has been the prevalent method used in industry, and researchers' focus on raising realism in estimates when using it seems not to be enough for the much-expected improvements. Instead of focusing on the estimation process's technicalities, we investigated the interaction of the establishment of commitments with customers and software estimation. By observing estimation sessions and interviewing software professionals from companies in varying contexts, we found that defensible estimates and padding of software estimates are crucial in converting estimates into commitments. Our findings show that software professionals use padding for three different reasons: contingency buffer, completing other tasks, or improving the overall quality of the product. The reasons to pad have a common theme: buying time to balance short- and long-term software development commitments, including the repayment of technical debt. Such a theme emerged from the human aspects of the interaction of estimation and the establishment of commitments: pressures and customers' conflicting short and longterm needs play silent and unrevealed roles in-between the technical activities. Therefore, our study contributes to untangling the underlying phenomena, showing how the practices used by software practitioners help to deal with the human and social context in which estimation is embedded.

Research has shown that gender diversity correlates positively with innovation and productivity in many professional engineering and technology domains. Yet, software development teams are dominated by males. In this paper, we aim at understanding whether female software professionals, compared to male, have different perceptions on a) team performance and dynamics, b) their own personal performance, c) their immediate supervisors, and d) accomplishment, recognition, and opportunities. Understanding perceptions of different genders can help software professionals, their supervisors and those responsible for staff create and foster environments in which both females and males are comfortable and perform best. To achieve this aim, we conducted a survey targeted at individual software professionals in technical roles. We collected and analyzed data from 55 female and 69 male respondents. Our results show basic differences in demographics (e.g., males tend to be older, have more senior roles, and have longer tenure with their employer). While we did find some differences around perceptions of spirit of team work, productivity, sense of satisfaction and fairness of reviews from supervisors, in general, females and males do not seem to differ significantly in their perceptions. Based on the results from our survey and insights from the current literature, we discuss commonalities and differences between females and males, and explore potential implications for performance reviews, recognition, and career progression.

Performance management has been considered as a critical tool aimed at strategically managing the contribution of human resources. As opposed to mere appraisal of performance, performance management as a process has a more holistic orientation which aims to define, facilitate, measure, and constantly improve performance at the individual, team, and organizational levels. The primary purpose of this study was to understand the perceptions of software professionals regarding certain performance management process dimensions (viz., performance planning, feedback, and employee participation in the process); system knowledge and justice dimensions (viz., procedural, distributive and interactional justice with respect to the performance management system) and their potential inter-relationship. The study was carried out on a sample of 341 software professionals in four software firms in the NCR region. Three survey instruments, i.e., perception of performance management process dimensions questionnaire, perceived system knowledge questionnaire, and perception of organizational justice dimensions questionnaire, were designed and used for the study. Results revealed that: Software professionals of all the four organizations were fairly satisfied with performance planning and their participation in performance management process; but only moderately satisfied with feedback. Perceived system knowledge of the software professionals was moderate. They perceived the performance management systems to be interactionally just to a large extent, but pointed towards a need for improvement on procedural and distributive dimensions. Significant positive correlation was seen between justice dimensions, performance management process dimensions, and perceived system knowledge. Inter-correlations within performance management process dimensions and justice dimensions were also positive and significant. Stepwise multiple regression analysis suggested feedback as the most significant predictor that explained maximum variance in each of the justice dimensions, viz., procedural, distributive, and interactional justice. The other two predictors were perceived system knowledge and employee participation in performance management process. Findings of this research have significant implications for HR practitioners. Feedback, perceived system knowledge and their participation in performance management process were found to be significant variables influencing their perceptions regarding fairness of the system and hence, may need specific attention especially in the software industry context. Strong inter-relationship was found amongst all dimensions relating to performance management process; perceived system knowledge, and justice dimensions pointing towards the significance of an integrated and systemic approach towards the process and have significant implications for improving the overall design, implementation, and outcomes of the performance management system.

Competency is able to drive a person to have good performance at work and is an objective measure of a person's collection of various personality traits. The key competency factors of software professionals can be divided into the following five groups: professional knowledge, application skills, initial capacity, quality characteristics and perception capability. On such basis we can construct the software professional competency model. After that we can take the following training countermeasures for software undergraduates: First we should pay more attention to the training of their professional knowledge and application skills; Second, college-enterprise cooperation should be strengthened to improve their initial capacity; Third, we should improve their quality characteristics and perception capability through the activities inside and outside class education.

Background: Many decisions made in Software Engineering practices are intertemporal choices: trade-offs in time between closer options with potential short-term benefit and future options with potential long-term benefit. However, how software professionals make intertemporal decisions is not well understood. Aim: This paper investigates how shifting time frames influence preferences in software projects in relation to purposefully selected background factors. Method: We investigate temporal discounting by replicating a questionnaire-based observational study. The replication uses a changed-population and -experimenter design to increase the internal and external validity of the original results. Results: The results of this study confirm the occurrence of temporal discounting in samples of both professional and student participants from different countries and demonstrate strong variance in discounting between study participants. We found that professional experience influenced discounting. Participants with broader professional experience exhibited less discounting than those with narrower experience. Conclusions: The results provide strong empirical support for the relevance and importance of temporal discounting in SE and the urgency of targeted interdisciplinary research to explore the underlying mechanisms and their theoretical and practical implications. The results suggest that technical debt management could be improved by increasing the breadth of experience available for critical decisions with long-term impact. In addition, the present study provides a methodological basis for replicating temporal discounting studies in software engineering.