Javier Gonzalez-Huerta

Ehsan Zabardast, Kwabena Ebo Bennin, Javier Gonzalez-Huerta

Context: Technical Debt (TD) discusses the negative impact of sub-optimal decisions to cope with the need-for-speed in software development. Code Technical Debt Items (TDI) are atomic elements of TD that can be observed in code artefacts. Empirical results on open-source systems demonstrated how code-smells, which are just one type of TDIs, are introduced and "survive" during release cycles. However, little is known about whether the results on the survivability of code-smells hold for other types of code TDIs (i.e., bugs and vulnerabilities) and in industrial settings. Goal: Understanding the survivability of code TDIs by conducting an empirical study analysing two industrial cases and 31 open-source systems from Apache Foundation. Method: We analysed 133,670 code TDIs (35,703 from the industrial systems) detected by SonarQube (in 193,196 commits) to assess their survivability using survivability models. Results: In general, code TDIs tend to remain and linger for long periods in open-source systems, whereas they are removed faster in industrial systems. Code TDIs that survive over a certain threshold tend to remain much longer, which confirms previous results. Our results also suggest that bugs tend to be removed faster, while code smells and vulnerabilities tend to survive longer.

Ehsan Zabardast, Javier Gonzalez-Huerta, Tony Gorschek et al.

Context: Developing software-intensive products or services usually involves a plethora of software artefacts. Assets are artefacts intended to be used more than once and have value for organisations; examples include test cases, code, requirements, and documentation. During the development process, assets might degrade, affecting the effectiveness and efficiency of the development process. Therefore, assets are an investment that requires continuous management. Identifying assets is the first step for their effective management. However, there is a lack of awareness of what assets and types of assets are common in software-developing organisations. Most types of assets are understudied, and their state of quality and how they degrade over time have not been well-understood. Method: We perform a systematic literature review and a field study at five companies to study and identify assets to fill the gap in research. The results were analysed qualitatively and summarised in a taxonomy. Results: We create the first comprehensive, structured, yet extendable taxonomy of assets, containing 57 types of assets. Conclusions: The taxonomy serves as a foundation for identifying assets that are relevant for an organisation and enables the study of asset management and asset degradation concepts.

Darja Smite, Nils Brede Moe, Eriks Klotins et al.

The COVID-19 outbreak has admittedly caused a major disruption worldwide. The interruptions to production, transportation, and mobility have clearly had a significant impact on the well-functioning of the global supply and demand chain. But what happened to the companies developing digital services, such as software. Were they interrupted as much or at all? And how has the enforced Working-From-Home mode impacted their ability to continue to deliver software? We hear that some managers are concerned that their engineers are not working effectively from home, or even lack the motivation to work in general, that teams lose touch and that managers do not notice when things go wrong. In this article, we share our findings from monitoring the situation in an international software company with engineers located in Sweden, USA, and the UK. We analyzed different aspects of productivity, such as developer satisfaction and well-being, activity, communication and collaboration, efficiency and flow based on the archives of commit data, calendar invites, and Slack communication, as well as the internal reports of WFH experiences and 18 interviews. We find that company engineers continue committing code and carry out their daily duties without significant disruptions, while their routines have gradually adjusted to the new norm with new emerging practices and various changes to the old ones. In a way, our message is that there is no news, which is good news. Yet, the experiences gained with the WFH of such scale have already made significant changes in the software industry's future, work from anywhere being an example of major importance.

Ehsan Zabardast, Julian Frattini, Javier Gonzalez-Huerta et al.

During the development and maintenance of software-intensive products or services, we depend on various artefacts. Some of those artefacts, we deem central to the feasibility of a project and the product's final quality. Typically, these central artefacts are referred to as assets. However, despite their central role in the software development process, little thought is yet invested into what eventually characterises as an asset, often resulting in many terms and underlying concepts being mixed and used inconsistently. A precise terminology of assets and related concepts, such as asset degradation, are crucial for setting up a new generation of cost-effective software engineering practices. In this position paper, we critically reflect upon the notion of assets in software engineering. As a starting point, we define the terminology and concepts of assets and extend the reasoning behind them. We explore assets' characteristics and discuss what asset degradation is as well as its various types and the implications that asset degradation might bring for the planning, realisation, and evolution of software-intensive products and services over time. We aspire to contribute to a more standardised definition of assets in software engineering and foster research endeavours and their practical dissemination in a common, more unified direction.

Javier Gonzalez-Huerta, Jefferson Seide Molleri, Aivars Šablis et al.

Background: Software project management activities help to introduce software process models in Software Engineering courses. However, these activities should be adequately aligned with the learning outcomes and support student's progression. Objective: Present and evaluate an approach to help students acquire theoretical and practical knowledge and experience real-world software projects' challenges. The approach combines a serious game and a design-implement task in which students develop a controlled-scale software system. Method: To evaluate our approach, we analyzed the students' perceptions collected through an online survey, their project plans, and their final reports using thematic analysis. Results: Results suggest that the approach promotes knowledge acquisition, enables students' progression, reinforces theoretical concepts, and is properly aligned with the course's learning outcomes. Conclusion: The approach seems to help to introduce software process models in Software Engineering courses. Our experience can also be inspiring for educators willing to apply our approach in similar courses.