Conference Paper

Technical Debt in Service-Oriented Software Systems

To read the full-text of this research, you can request a copy directly from the authors.


Service-Oriented Architectures (SOA) have become a standard for developing software applications, including but not limited to cloud-based ones and enterprise systems. When using SOA, the software engineers organize the desired functionality into self-contained and independent services, that are invoked through end-points (API calls). At the maintenance phase, the tickets (bugs, functional updates, new features, etc.) usually correspond to specific services. Therefore, for maintenance-related estimates it makes sense to use as unit of analysis the service-per se, rather than the complete project (too coarse-grained analysis) or a specific class (too fine-grained analysis). Currently, some of the most emergent maintenance estimates are related to Technical Debt (TD), i.e., the additional maintenance cost incurred due to code or design inefficiencies. In the literature, there is no established way on how to quantify TD at the service level. To this end, in this paper, we present a novel methodology to measure the TD of each service considering the underlying code that supports the corresponding endpoint. The proposed methodology relies on the method call graph, initiated by the service end-point, and traverses all methods that provide the service functionality. To evaluate the usefulness of this approach, we have conducted an industrial study, validating the methodology (and the accompanying tool) with respect to usefulness, obtained benefits, and usability.

No full-text available

Request Full-text Paper PDF

To read the full-text of this research,
you can request a copy directly from the authors.

ResearchGate has not been able to resolve any citations for this publication.
Full-text available
There are numerous commercial tools and research prototypes that offer support for measuring technical debt. However, different tools adopt different terms, metrics, and ways to identify and measure technical debt. These tools offer diverse features, and their popularity / community support varies significantly. Therefore, (a) practitioners face difficulties when trying to select a tool matching their needs; and (b) the concept of technical debt and its role in software development is blurred. We attempt to clarify the situation by comparing the features and popularity of technical debt measurement tools, and analyzing the existing empirical evidence on their validity. Our findings can help practitioners to find the most suitable tool for their purposes, and researchers by highlighting the current tool shortcomings
Full-text available
Software teams are often asked to deliver new features within strict deadlines leading developers to deliberately or inadvertently serve “not quite right code” compromising software quality and maintainability. This non-ideal state of software is efficiently captured by the Technical Debt (TD) metaphor, which reflects the additional effort that has to be spent to maintain software. Although several tools are available for assessing TD, each tool essentially checks software against a particular ruleset. The use of different rulesets can often be beneficial as it leads to the identification of a wider set of problems; however, for the common usage scenario where developers or researchers rely on a single tool, diverse estimates of TD and the identification of different mitigation actions limits the credibility and applicability of the findings. The objective of this study is two-fold: First, we evaluate the degree of agreement among leading TD assessment tools. Second, we propose a framework to capture the diversity of the examined tools with the aim of identifying few “reference assessments” (or class/file profiles) representing characteristic cases of classes/files with respect to their level of TD. By extracting sets of classes/files exhibiting similarity to a selected profile (e.g., that of high TD levels in all employed tools) we establish a basis that can be used either for prioritization of maintenance activities or for training more sophisticated TD identification techniques. The proposed framework is illustrated through a case study on fifty (50) open source projects and two programming languages (Java and JavaScript) employing three leading TD tools.
Full-text available
Several companies are re-architecting their monolithic information sys- tems with microservices. However, many companies migrated without experience on microservices, mainly learning how to migrate from books or from practitioners’ blogs. Because of the novelty of the topic, practitioners and consultancy are learning by doing how to migrate, thus facing several issues but also several benefits. In this chapter, we introduce a catalog and a taxonomy of the most common microservices anti-patterns in order to identify common problems. Our anti-pattern catalogue is based on the experience summarized by different practitioners we interviewed in the last three years. We identified a taxonomy of 20 anti-patterns, including orga- nizational (team oriented and technology/tool oriented) anti-patterns and technical (internal and communication) anti-patterns. The results can be useful to practitioners to avoid experiencing the same difficult situations in the systems they develop. More- over, researchers can benefit of this catalog and further validate the harmfulness of the anti-patterns identified.
Conference Paper
Full-text available
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.
Full-text available
Context: Technical debt (TD) is a metaphor reflecting technical compromises that can yield short-term benefit but may hurt the long-term health of a software system. Objective: This work aims at collecting studies on TD and TD management (TDM), and making a classification and thematic analysis on these studies, to obtain a comprehensive understanding on the TD concept and an overview on the current state of research on TDM. Method: A systematic mapping study was performed to identify and analyze research on TD and its management, covering publications between 1992 and 2013. Results: Ninety-four studies were finally selected. TD was classified into ten types, eight TDM activities were identified, and twenty-nine tools for TDM were collected. Conclusions: The term “debt” has been used in different ways by different people, which leads to ambiguous interpretation of the term. Code-related TD and its management have gained the most attention. There is a need for more empirical studies with high-quality evidence on the whole TDM process and on the application of specific TDM approaches in industrial settings. Moreover, dedicated TDM tools are needed for managing various types of TD in the whole TDM process.
Conference Paper
Full-text available
A Cloud-based Service-Oriented Architecture (CBSOA) is typically composed of web services, which are offered off the cloud marketplace. CB-SOA can improve its utility and add value to its composition by switching among its constituent services. We look at the option to defer the decision of substitution under uncertainty. We exploit Binomial Options to the formulation. We quantify the time-value of the architecture decisions of switching web services and technical debt they can imply on the structure. As CB-SOA are market-sensitive, dynamic and "volatile", the decision of deferral tends to be sensitive to these dynamics. Henceforth, the structural complexity of a CB-SOAcan change over time and so the technical debt as its constituent web services are modified, replaced, upgraded, etc. The method builds on Design Structure Matrix (DSM) and introduces time and complexity aware propagation cost metrics to assess the value of deferral decisions relative to changes in the structure. Architects of CB-SOA can use our method to assess the time value of deferring the decisions to switch web services relative to complexity, technical debt and value creation. We demonstrate the applicability of the method using an illustrative example.
Conference Paper
Full-text available
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
Conference Paper
Full-text available
“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.
Technical Debt (TD) is a successful metaphor in conveying the consequences of software inefficiencies and their elimination to both technical and non-technical stakeholders, primarily due to its monetary nature. The identification and quantification of TD rely heavily on the use of a small handful of sophisticated tools that check for violations of certain predefined rules, usually through static analysis. Different tools result in divergent TD estimates calling into question the reliability of findings derived by a single tool. To alleviate this issue we use 18 metrics pertaining to source code, repository activity, issue tracking, refactorings, duplication and commenting rates of each class as features for statistical and Machine Learning models, so as to classify them as High-TD or not. As a benchmark we exploit 18,857 classes obtained from 25 Java projects, whose high levels of TD has been confirmed by three leading tools. The findings indicate that it is feasible to identify TD issues with sufficient accuracy and reasonable effort: a subset of superior classifiers achieved an F 2-measure score of approximately 0.79 with an associated Module Inspection ratio of approximately 0.10. Based on the results a tool prototype for automatically assessing the TD of Java projects has been implemented.
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.
Growing number of reports on the problems with SOA projects indicates that SOA faces substantial problems. It can be a consequence of the fact that SOA passes the disgustion phase of the hypo curve. It, however, must have some concrete reasons. We analyze frequently used and often even recommended SOA development practices and processes and we show that the processes implicitly apply few known and usually most important SOA antipatterns. The cure is not easy. We show using causal diagrams to analyze dependencies that the practices involve developing (unstable) causal cycles. It requires strong managerial countermeasures a a careful analysis. We show that the most important is to avoid fine-grained services and interfaces.
Conference Paper
Software teams, as they communicate throughout the life-cycle of their projects, generate a substantial stream of textual data. Through emails and chats, developers discuss the requirements of their software system, they negotiate the distribution of tasks among them, and they make decisions about the system design, and the internal structure and functionalities of its code modules. The software research community has long recognized the importance and potential usefulness of such textual information. In this paper, we discuss our recent work on systematically analyzing several textual streams collected through our WikiDev2.0 tool. We use two different text-analysis methods to examine five different sources of textual data. We report on our experience using our method on analyzing the communications of a nine-member team over four months.
This paper is a description of inductive and deductive content analysis. Content analysis is a method that may be used with either qualitative or quantitative data and in an inductive or deductive way. Qualitative content analysis is commonly used in nursing studies but little has been published on the analysis process and many research books generally only provide a short description of this method. When using content analysis, the aim was to build a model to describe the phenomenon in a conceptual form. Both inductive and deductive analysis processes are represented as three main phases: preparation, organizing and reporting. The preparation phase is similar in both approaches. The concepts are derived from the data in inductive content analysis. Deductive content analysis is used when the structure of analysis is operationalized on the basis of previous knowledge. Inductive content analysis is used in cases where there are no previous studies dealing with the phenomenon or when it is fragmented. A deductive approach is useful if the general aim was to test a previous theory in a different situation or to compare categories at different time periods.
Proceedings on Objectoriented programming systems, languages, and applications
  • W Cunningham
W. Cunningham, "The WyCash Portfolio Management System," Proceedings on Objectoriented programming systems, languages, and applications, pp. 29-0, 992.
Microservices tenets
  • O Zimmermann
O. Zimmermann, "Microservices tenets," Comput. Sci. -Res. Dev., Jul. 2017.
Architectural Technical Debt in Microservices: A Case Study in a Large Company
  • S Soares De Toledo
  • A Martini
  • A Przybyszewska
  • D I K Sjøberg
S. Soares de Toledo, A. Martini, A. Przybyszewska and D. I. K. Sjøberg, "Architectural Technical Debt in Microservices: A Case Study in a Large Company," 2019 IEEE/ACM International Conference on Technical Debt (TechDebt), 2019, pp. 78-87.
On the lack of consensus among technical debt detection tools
  • J Lefever
  • Y Cai
  • H Cervantes
  • R Kazman
  • H Fang
J. Lefever, Y. Cai, H. Cervantes, R. Kazman, H. Fang, "On the lack of consensus among technical debt detection tools." Proceedings of the International Conference on Software Engineering (SEIP); 2021:121-130.
A Machine Learning-Based Approach to Detect Web Service Design Defects
  • A Ouni
  • M Daagi
  • M Kessentini
  • S Bouktif
  • M M Gammoudi
A. Ouni, M. Daagi, M. Kessentini, S. Bouktif and M. M. Gammoudi, "A Machine Learning-Based Approach to Detect Web Service Design Defects," Int. Conf. on Web Services (ICWS), 2017, pp. 532-539.
Javaparser: visited". Leanpub
  • N Smith
  • D Van Bruggen
  • F Tomassetti
N. Smith, D. Van Bruggen, and F. Tomassetti, "Javaparser: visited". Leanpub, Oct. 2017
System Usability Scale (SUS): A quick-and-dirty method of system evaluation user information
  • J Brooke
J. Brooke, J. "System Usability Scale (SUS): A quick-and-dirty method of system evaluation user information", Taylor & Francis, 1996.