Context: Making architectural decisions is a crucial task but also very difficult, considering the scope of the decisions and their impact on quality attributes.To make matters worse, architectural decisions need to combine both technical and business factors, which are very dissimilar by nature.Objectives: We provide a cost-benefit approach and supporting tooling that treats architectural decisions as financial investments by: (a) combining both technical and business factors; and (b) transforming the involved factors into currency, allowing their uniform aggregation.Apart from illustrating the method, we validate both the proposed approach and the tool, in terms of fitness for purpose, usability, and potential limitations.Method: To validate the approach, we have performed a case study in a software development company, in the domain of low-energy embedded systems.We employed triangulation in the data collection phase of the case study, by performing interviews, focus groups, an observational session, and questionnaires.Results: The results of the study suggested that the proposed approach: (a) provides a structured process for systematizing decision-making; (b) enables the involvement of multiple stakeholders, distributing the decision-making responsibility to more knowledgeable people; (c) uses monetized representations that are important for assessing decisions in a unified manner; and (d) enables decision reuse and documentation. Conclusions:The results of the study suggest that architectural decision-making can benefit from treating this activity as a financial investment.The various benefits that have been identified from mixing financial and technological aspects are well-accepted from industrial stakeholders.

Due to the rapid advancements in the hardware architectures of High-Performance Computing infrastructures, new challenges have arisen in the development of scientific software applications. In particular, software that runs on Exascale machines, needs to be highly portable, highly parallelizable and at the same time maintainable, since software for HPC evolves constantly over time. By taking into account that an overall optimization of all the aforementioned qualities is not realistic, in this study, we explore the possible trade-offs, when optimizing the run-time qualities of the software (i.e., performance and portability) through state-of-practice techniques in Exascale software development, in expense of code maintainability, as expressed by technical debt. To achieve this goal, we have performed a case study, in which the effect of run-time optimizations on technical debt has been measured. The results suggest that run-time optimizations tend to reduce TD principal, whereas the effect on interest is not consistent. The results are discussed in detail in this paper from the point of view of both researchers and practitioners.

The cornerstones of technical debt (TD) are two concepts borrowed from economics: principal and interest. Although in economics the two terms are related, in TD there is no study on this direction so as to validate the strength of the metaphor. We study the relation between Principal and Interest, and subsequently dig further into the ‘ingredients’ of each concept (since they are multi-faceted). In particular, we investigate if artifacts with similar levels of TD Principal exhibit a similar amount of TD Interest, and vice-versa. To achieve this goal, we performed an empirical study, analyzing the dataset using the Mantel test. Through the Mantel test, we examined the relation between TD Principal and Interest, and identified aspects that are able to denote proximity of artifacts, with respect to TD. Next, through Linear Mixed Effects (LME) modelling we studied the generalizability of the results. The results of the study suggest that TD Principal and Interest are related, in the sense that classes with similar levels of TD Principal tend to have similar levels of Interest. Additionally, we have reached the conclusion that aggregated measures of TD Principal or Interest are more capable of identifying proximate artifacts, compared to isolated metrics. Finally, we have provided empirical evidence on the fact that improving certain quality properties (e.g., size and coupling) should be prioritized while ranking refactoring opportunities in the sense that high values of these properties are in most of the cases related to artifacts with higher levels of TD Principal. The findings shed light on the relations between the two concepts, and can be useful for both researchers and practitioners: the former can get a deeper understanding of the concepts, whereas the latter can use our findings to guide their TD management processes such as prioritization and repayment.

Refactoring is a prevalent technique that can be applied for improving software structural quality. Refactorings can be applied at different levels of granularity to resolve 'bad smells' that can be identified in various artifacts (e.g., methods, classes, packages). A fundamental software engineering principle that can be applied at various levels of granularity is the Single Responsibility Principle (SRP), whose violation leads to the creation of lengthy, complex and non-cohesive artifacts; incurring smells like Long Method, God Class, and Large Package. Such artifacts, apart from being large in size tend to implement more than one functionalities, leading to decreased cohesion, and increased coupling. In this paper, we study the effect of applying refactorings that lead to conformance to the SRP, at all three levels of granularity to identify possible differences between them. To study these differences, we performed an industrial case study on two large-scale software systems (more than 1,500 classes). Since SRP is by definition related to modularity, as a success measure for the refactoring we use coupling and cohesion metrics. The results of the study can prove beneficial for both researchers and practitioners, since various implications can be drawn.