Public cloud services are integral to modern software development, oeringscalability and exibility to organizations.Based on customer requests, alarge product development organization considered migrating the microservice-based product deployments of a large customer to a public cloud provider.

We conducted an exploratory single-case study, utilizing quantitative andqualitative data analysis to understand how and why deployment costs wouldchange when transitioning the product from a private to a public cloud en-vironment while preserving the software architecture. We also isolated themajor factors driving the changes in deployment costs.

We found that switching to the customer-chosen public cloud providerwould increase costs by up to 50%, even when sharing some resources be-tween deployments, and limiting the use of expensive cloud services such assecurity log analyzers. A large part of the cost was related to the sizing andlicense costs of the existing relational database, which was running on Vir-tual Machines in the cloud. We also found that existing system integrators,using the product via its API, were likely to use the product ineciently, inmany cases causing at least 10% more load to the system than needed.

From a deployment cost perspective, successful migration to a publiccloud requires considering the entire system architecture, including serviceslike relational databases, value-added cloud services, and enabled productfeatures. Our study highlights the importance of leveraging end-to-end us-age data to assess and manage these cost drivers eectively, especially inenvironments with elastic costs, such as public cloud deployments.

Context: In software development organizations employing weak or collective ownership, different teams are allowed and expected to autonomously perform changes in various components. This creates diversity both in the knowledge of, and in the responsibility for, individual components.

Objective: Our objective is to understand how and why different teams introduce technical debt in the form of code clones as they change different components.

Method: We collected data about change size and clone introductions made by ten teams in eight components which was part of a large industrial software system. We then designed a Multi-Level Generalized Linear Model (MLGLM), to illustrate the teams’ differing behavior. Finally, we discussed the results with three development teams, plus line manager and the architect team, evaluating whether the model inferences aligned with what they expected. Responses were recorded and thematically coded.

Results: The results show that teams do behave differently in different components, and the feedback from the teams indicates that this method of illustrating team behavior can be useful as a complement to traditional summary statistics of ownership.

Conclusions: We find that our model-based approach produces useful visualizations of team introductions of code clones as they change different components. Practitioners stated that the visualizations gave them insights that were useful, and by comparing with an average team, inter-team comparisons can be avoided. Thus, this has the potential to be a useful feedback tool for teams in software development organizations that employ weak or collective ownership. © The Author(s) 2024.

Context The micro-services architectural pattern advocates for the partitioning of functionality into loosely coupled services, which should be backward compatible, to enable independent upgrades. Deprecation is commonly used as a tool to manage multiple versions of methods or services. However, deprecation carries a cost in that tests might be duplicated and might rely on services that have become deprecated over time. Objective Using the terms of the Technical Debt metaphor, we explore the consequences of deprecation, and how it has affected the test base during seven years. Method We take an exploratory approach, reporting on experiences found before and after servicing parts of the incurred Technical Debt. We mine code repositories and validate our findings with experienced developers. Results We found that the growth of deprecation debt varied a lot. Some services experienced substantial growth, but most did not. Unit tests, where deprecation is visible in the developers' tools, were much less affected than integration tests, which lack such visualization mechanisms. While servicing debt of 121 out of 285 deprecated services, we discovered that up to 29% of the spent effort could be attributed to accrued interest. However, this is an upper bound; there could be less impact, depending on whether scripting could be used to service the debt or not. Conclusion This paper illustrates that integration tests can be viewed as a debt from the perspective of deprecated services. While the pattern was that deprecated services (debt principal) experienced no or little accrued interest, some, highly used, services experienced a lot, particularly during stressful times. Java-based tests, where deprecation is visible in the IDE, did not experience a similar pattern of increasing debt. We postulate that deprecation debt should be kept visible, either using developer tools or statistical reports. © 2020 ACM.

Context:   The concept of software craftsmanship has early roots in computing, and in 2009, the Manifesto for Software Craftsmanship was formulated as a reaction to how the Agile methods were practiced and taught. But software craftsmanship has seldom been studied from a software engineering perspective.  

Objective:  The objective of this article is to systematize an anatomy of software craftsmanship through literature studies and a longitudinal case study.     

Method:  We performed a snowballing literature review based on an initial set of nine papers, resulting in~18 papers and 11 books.  We also performed a case study following seven years of software development of a product for the financial market, eliciting qualitative and quantitative results.  We used thematic coding to synthesize the results into categories.

Results:  The resulting anatomy is centered around four themes, containing 17 principles and 47 hierarchical practices connected to the principles.  We present the identified practices based on the experiences gathered from the case study, triangulating with the literature results.

Conclusion: We provide our systematically derived anatomy of software craftsmanship with the goal of inspiring more research into the principles and practices of software craftsmanship and how these relate to other principles within software engineering in general.