In a large-scale software development product development organization, we found that most developers, although experienced, were lacking architectural knowledge of the specific developed product.

As a remedy, we evaluated whether we could stimulate learning the product architecture by conducting training in how to use the product’s distributed tracing platform, built on the OpenTelemetry standard and the open-source Jaeger Tracing visualization tool.

We planned and participated in a training event, where parts of the organization explored, using experiential learning, how to set up and use tracing to troubleshoot a realistic fault scenario we prepared. Respondents were asked to rate the tool according to the Technology Adoption Model (TAM), and responses were collected on Likert-type scales, analyzed, and summarized using a Bayesian workflow.

Even as tool usage post-training was low, respondents still had a positive attitude toward using the tool, valued the experiential training, and expressed a strong intent to use the tool for program comprehension.

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.

Background: Books on software craftsmanship typically focus on small teams or individual behavior, and are seldom associated with large, globally distributed organizations that develop and maintain long-lived software systems.

Objective: This thesis aims to quantify the effects of systematically derived aspects of software craftsmanship in industrial settings involving large-scale organizations, with developers spread around the globe.

Method: We employ mixed-methods studies, utilizing both qualitative and quantitative data collection and analysis. A Systematic Literature Review (SLR), together with a longitudinal industrial case study, is used to derive an initial anatomy of software craftsmanship, and we use case studies, experience reports and action research to explore and quantify aspects of this anatomy. We use Bayesian methods to analyze data obtained via archival analysis, as well as Likert-scale data obtained froma survey using the Technology Adoption Model (TAM). Qualitative data has been analyzed using thematic coding, and we use focus groups to validate our conclusions with the studied subjects.

Results: Based on the SLR results and a industrial case study, we derive an anatomy of software craftsmanship, based on four themes, 17 principles and 47 practices. The effects of some practices from this anatomy are then quantified in subsequent articles in the thesis.

Conclusion: Based on literature and case study results, we have found a usable conceptual map of software craftsmanship. However, it remains to be seen how this map will stay relevant, in the face of how cloud migrations and AI-powered Large-Language Model tools will impact future software engineers.

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.

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.

In this paper, we present experiences from eight years of developing a financial transaction engine, using what can be described as an integration-test-centric software development process.We discuss the product and the relation between three different categories of its software and how the relative weight of these artifacts has varied over the years.In addition to the presentation, some challenges and future research directions are discussed.

Since its inception, software development has been recognized as a highly technical activity, where, at times, highly skilled professionals have been tempted to face technical problems on their own. In the past, software developers, may have been inclined to create solutions as if they were the only ones who needed to understand the solutions.

However, nowadays, the disciplines of software development and systems development have undergone significant change. Current software development requires more crafting skills, in addition to engineering skills. The lone-cowboy programmer will soon have no place in properly organised software development projects. Current practices demand that a productive programmer be tasked to develop both working software (as claimed in the Agile Manifesto) and well crafted software. Accountability, pride in one's work, continuous learning and mentorship are characteristics of the profession that we should promote if we want to enable an attitude of craftsmanship within software development.

This paper provides experiences of craftsmanship, and argues why software craftsmanship is good for the practitioner and software development organizations. To support this claim, we have analysed the development of a product that was developed by following several craftsmanship principles. We observed the product's development for seven years, and interviewed several professionals who were involved in its development.

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.