In DevOps, the traceability of software artifacts is critical to the successful development and operation of project delivery to stakeholders. This paper reports on the experience of developers using DevOps for developing and productionising a Javascript React web application, with a focus on traceability management of artifacts produced throughout the life cycle. This report also highlights key opportunities and challenges in traceability management from the development stage to production.
On the Energy Consumption and Performance of WebAssembly Binaries across Programming Languages and Runtimes in IoT
Context. WebAssembly (WASM) is a low-level bytecode format that is gaining traction among Internet of Things (IoT) devices. Because of IoT devices’ resources limitations, Using WASM is becoming a popular technique for virtualization on IoT devices. However, it is unclear if the promises of WASM regarding its efficient use of energy and performance gains hold true. Goal. This study aims to determine how different source programming languages and runtime environments affect the energy consumption and performance of WASM binaries. Method. We perform a controlled experiment where we compile three benchmarking algorithms from four different programming languages (i.e., C, Rust, Go, and JavaScript) to WASM and run them using two different WASM runtimes on a Raspberry Pi 3B. Results. The source programming language significantly influences the performance and energy consumption of WASM binaries. Differently, we did not find evidence of the impact of the runtime environment. However, certain combinations of source programming language and runtime environment leads to a significant improvement of its energy consumption and performance. Conclusions. IoT developers should choose the source programming language wisely to benefit from increased performance and a significant reduction in energy consumption. Specifically, JavaScript should be generally avoided, while C and Rust are better options.
Functional Size Measurement in Agile Development - Velocity in Agile Sprints
Industry Perspective Paper
Agile teams measure their velocity for performance, based on Story Points. However, such velocity does not allow predicting when the product will be finished. Story points measure effort only. They do not discriminate between creating functionality and other tasks. Non-functional requirements, such as agreeing with stakeholders, designing, testing, or documenting, consume effort but do not add functionality. Thus, it remains unclear whether the product makes any progress, or the team is just looping around technical debt and unclear requirements. Euro Project Office has therefore developed a method how to complement a product backlog by functional size, indicating progress and completeness in unambiguous terms. The method is based on the international standard ISO/IEC 14143 and ISO/IEC 19761. Tools are available as open source and can be used by development teams with minimum investment into training.
Investigating Software Engineering Artifacts in DevOps Through the Lens of Boundary Objects
The use of software engineering artifacts in DevOps is central to enabling collaboration between involved teams when integrating the development and operations domains. At the same time, collaboration around DevOps artifacts has yet to receive detailed research attention. To address this research gap, we explore the specific software engineering artifacts that act as a means of translation between DevOps stakeholders. We apply the sociological concept of Boundary Objects, which has been used to describe, analyze, and evaluate artifacts that enable a cross-disciplinary understanding. While Boundary Objects have not been explicitly studied in DevOps contexts, they appear promising to investigate how different teams can collaborate efficiently using common artifacts. We performed a multiple case study and conducted twelve semi-structured interviews with DevOps practitioners in nine companies. We elicited participants’ collaboration practices, focusing on the coordination of stakeholders and the use of engineering artifacts as Boundary Objects. This paper presents a consolidated overview of four categories of DevOps Boundary Objects and eleven stakeholder groups relevant to DevOps. To help practitioners assess cross-disciplinary knowledge management strategies, we detail how DevOps Boundary Objects contribute to four areas of DevOps knowledge and propose dimensions to evaluate their use.
The complexity of delivering enterprise-grade software, especially as-a-service, keeps getting more sophisticated even with the large set of open-source and commercial helper tools. Every single commit by the developers must go through a large group of checks to ensure that it won’t break or regress reliability, resiliency, security, compliance, privacy, performance, accessibility, operability, etc. Being a developer in such an environment is not a fulfilling role at all. Full stack, as a notion, is not applicable to large-scale systems and enterprise software. We are introducing a new, horizontal, approach called “full-spec software” where each layer of the system is architected, designed, and built with the long list of enterprise readiness attributes listed above. Making full-spec software a reality requires a new organizational construct called “platform engineering.”
On Improving Pair Programming in University Classrooms
Short Paper
[Context] With the recent advent of artificially intelligent pairing partners in software engineering, it is interesting to renew the study of the psychology of pairing. Pair programming provides an attractive way of teaching software engineering to university students. Its study can also lead to a better understanding of the needs of professional software engineers in various programming roles and for the improvement of the concurrent pairing software. [Objective] This preliminary study aimed to gain quantitative and qualitative insights into pair programming, especially students’ attitudes towards its specific roles and what they require from the pairing partners. The research’s goal is to use the findings to design further studies on pairing with artificial intelligence. [Method] Using a mixed-methods and experimental approach, we distinguished the effects of the pilot, navigator, and solo roles on (N = 35) students’ intrinsic motivation. Four experimental sessions produced a rich data corpus in two software engineering university classrooms. It was quantitatively investigated using the Shapiro-Wilk normality test and one-way analysis of variance (ANOVA) to confirm the relations and significance of variations in mean intrinsic motivation in different roles. Consequently, seven semi-structured interviews were conducted with the experiment’s participants. The qualitative data excerpts were subjected to the thematic analysis method in an essentialist way. [Results] The systematic coding interview transcripts elucidated the research topic by producing seven themes for understanding the psychological aspects of pair programming and for its improvement in university classrooms. Statistical analysis of 612 self-reported intrinsic motivation inventories confirmed that students find programming in pilot-navigator roles more interesting and enjoyable than programming simultaneously. [Conclusion] The executed experimental settings are viable for inspecting the associations between students’ attitudes and the distributed cognition practice. The preliminary results illuminate the psychological aspects of the pilot-navigator roles and reveal many areas for improvement. The results also provide a strong basis for conducting further studies with the same design involving the big five personality and intrinsic motivation on using artificial intelligence in pairing and to allow comparison of those results with results of pairing with human partners.
Using InnerSource for Improving Internal Reuse: An Industrial Case Study
Xingru Chen, Muhammad Usman and Deepika Badampudi
Background: InnerSource helps improve software reuse through increased transparency and inter-team collaboration. Companies need to understand their context and specific needs before deciding to adopt any specific InnerSource practices since they cannot apply all InnerSource practices at once. Aim This study aims to support the case company in assessing its readiness for adopting InnerSource practices to improve its internal reuse, identify and prioritize the improvement areas, and identify suitable solutions. Method: We performed a case study using a questionnaire and a workshop to check the current and desired status of adopting InnerSource practices and collect potential solutions. Results: The study participants identified that the company needs to prioritize the improvements related to the discoverability, communication channels, and ownership of the reusable assets. In addition, they identified certain InnerSource practices as solutions for the prioritized improvement areas, such as better structured repositories for storing and searching the reusable assets and standardized documentation of the reusable assets. Conclusion: The questionnaire instrument aids the case company in identifying the improvement areas related to InnerSource and reuse practices. InnerSource practices could improve the development and maintenance of reusable assets.
Artifact Traceability in DevOps: An Industrial Experience Report
Industry Experience Report
In DevOps, the traceability of software artifacts is critical to the successful development and operation of project delivery to stakeholders. This paper reports on the experience of developers using DevOps for developing and productionising a Javascript React web application, with a focus on traceability management of artifacts produced throughout the life cycle. This report also highlights key opportunities and challenges in traceability management from the development stage to production.
