Software architecture social debt:managing the incommunicability factor

Architectural technical debt is the additional project cost connected to technical issues nested in software architectures. Similarly, many practitioners have already experienced that there exists within software architectures a form of social debt, that is, the additional project cost connected to sociotechnical and organizational issues evident in or related to software architectures. This paper illustrates four recurrent antipatterns or community smells connected to such architectural social debt and outlines a means to measure the additional project cost connected to their underlying cause: decision incommunicability. Evaluating the results in multiple focus groups, this paper concludes that studying social debt and community smells at the architecture level may prove vital to rid software development communities of critical organizational flaws incurring considerable additional cost.</p

Cognitive distance and research output in computing education:a case-study

Contribution: This paper quantifies the phenomenon of more versus better research output in computing research education and elaborates on how the organizational variable known as cognitive distance plays a fundamental role in mediating such more versus better research output relation. Background: To improve the current educational system, investigation and quantification is needed of the 'silos.' Cognitive distance - a measure of the differences in background, culture, and expertise between collaborators - may be a factor influencing the lack of quality and variety in research outputs. Addressing this is a key enabler for fruitful collaboration. Research Question: Does collaboration with similarly expert researchers yield better research? Methodology: A quantitative survey provides baseline data for cognitive distance while publication data allowed creation of a co-authorship network between 123 researchers in a European computing research department. The network was analyzed through quantitative and qualitative research methods. Findings: Increased expertise overlaps across sub-fields of computing is a strong predictor for further collaboration (quantity), but research impact (quality) decreases with larger overlaps. This reveals an educational silo effect in doctoral computing education and, consequently, a flaw in the connected research output. The lack of a single, agreed way to evaluate research impact across sub-fields further hinders cross-departmental collaboration among doctoral students. Conclusion: Three recommendations emerge for policy makers and educational leaders: 1) departments should be cross-functional and focused on societal interests; 2) communities of practice should be created at the level of doctoral education and upward; and 3) departments should hold matchmaking and speed-meeting events regularly within and across institutions.</p

Unveiling and unraveling aggregation and dispersion fallacies in group MCDM

Priorities in multi-criteria decision-making (MCDM) convey the relevance preference of one criterion over another, which is usually reflected by imposing the non-negativity and unit-sum constraints. The processing of such priorities is different than other unconstrained data, but this point is often neglected by researchers, which results in fallacious statistical analysis. This article studies three prevalent fallacies in group MCDM along with solutions based on compositional data analysis to avoid misusing statistical operations. First, we use a compositional approach to aggregate the priorities of a group of DMs and show that the outcome of the compositional analysis is identical to the normalized geometric mean, meaning that the arithmetic mean should be avoided. Furthermore, a new aggregation method is developed, which is a robust surrogate for the geometric mean. We also discuss the errors in computing measures of dispersion, including standard deviation and distance functions. Discussing the fallacies in computing the standard deviation, we provide a probabilistic criteria ranking by developing proper Bayesian tests, where we calculate the extent to which a criterion is more important than another. Finally, we explain the errors in computing the distance between priorities, and a clustering algorithm is specially tailored based on proper distance metrics

Architectural Tactics for Energy Efficiency: Review of the Literature and Research Roadmap

The energy consequences of software are rapidly growing: at the high-end, server farms consume enormous amounts of energy; at the low-end there is ever-increasing emphasis on battery-powered mobile and Internet-of-Things (IoT) devices with equally increasing complex usage scenarios. Conversely, there has been little attention to how software architectures can be designed for energy efficiency. While other software qualities—--think of performance or availability--—have been extensively studied, there is little research on how to reason about energy-consumption as a first-class citizen. We provide a basis for reasoning about design decisions for energy efficiency by deriving a kit of reusable architectural tactics derived from literature. We use the well-known open-search and snowballing methodologies to attain primary studies, and subsequently used thematic coding of such studies to identify recurrences and commonalities among the design strategies presented. The result of this process is a set of 10 architectural tactics for energy efficiency. These tactics provide a rational basis for architectural design and analysis for energy efficiency

Exploring community smells in open-source:an automated approach

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

Splicing Community and Software Architecture Smells in Agile Teams: An industrial Study

Software engineering nowadays largely relies on agile methods to carry out software development. In often highly distributed organizations, agile teams can develop organisational and socio-technical issues loosely defined as community smells, which reflect sub-optimal organisational configurations that bear additional project cost, a phenomenon called social debt. In this paper we look into the co-occurrence of such nasty organisational phenomena—community smells—with software architecture smells—indicators that software architectures may exhibit sub-optimal modularization structures, with consequent additional cost. We conclude that community smells can serve as a guide to steer the qualities of software architectures within agile teams