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.

Methods:We performed an analysis of secondary literature and a field study at five companies to investigate and identify assets to fill the gap in research. The results were analysed qualitatively and summarised in a taxonomy.

Results:We present 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.

Seeking the advantages delivered by agile methods in small-scale software development, large organisations are also adopting agile methods. However, scaling results in a huge growth of socio-technical dependencies that can lead to waiting time, delays, and defects and hinder the teams' ability to recognize their own responsibilities. This research proposes an approach to enable teams' autonomy and clarifies teams' responsibility assignments by aligning socio-technical dependencies. By utilising compile-time, run-time, and task dependencies, our approach identifies the wasteful dependencies between the social structures (teams) and the corresponding technical structures (architecture) and also suggests improvements. The initial results suggest that the approach correctly identifies the wasteful dependencies that are hindering teams' responsibility assignments. The suggested solution proposals are also considered useful. Awareness of such wasteful dependencies is the first step toward being able to handle them successfully. © 2023 IEEE.

Context

Advances in technical debt research demonstrate the benefits of applying the financial debt metaphor to support decision-making in software development activities. Although decision-making during requirements engineering has significant consequences, the debt metaphor in requirements engineering is inadequately explored.

Objective

We aim to conceptualize how the debt metaphor applies to requirements engineering by organizing concepts related to practitioners’ understanding and managing of requirements engineering debt (RED).

Method

We conducted two in-depth expert interviews to identify key requirements engineering debt concepts and construct a survey instrument. We surveyed 69 practitioners worldwide regarding their perception of the concepts and developed an initial analytical theory.

Results

We propose a RED theory that aligns key concepts from technical debt research but emphasizes the specific nature of requirements engineering. In particular, the theory consists of 23 falsifiable propositions derived from the literature, the interviews, and survey results.

Conclusions

The concepts of requirements engineering debt are perceived to be similar to their technical debt counterpart. Nevertheless, measuring and tracking requirements engineering debt are immature in practice. Our proposed theory serves as the first guide toward further research in this area.

While modern software companies strive to increase team autonomy to enable them to successfully operate the piece of software they develop and deploy, efficient ways to orchestrate the work of multiple autonomous teams working in parallel are still poorly understood. In this paper, we report how team autonomy is maintained at Spotify at scale, based on team retrospectives, interviews with team managers and archival analysis of corporate databases and work procedures. In particular, we describe how managerial authority is decentralized through various workgroups with collective authority, what compromises are made to team autonomy to ensure alignment and which team-related factors can further hinder autonomy. Our findings show that scaled autonomy at Spotify does not mean anarchy, or unlimited permissiveness. Instead, squads are expected to take responsibility for their work and coordinate, communicate and align their actions with others, and comply with a few enabling constraints. Further, squads take many decisions independently without management control or due to collective efforts that bypass formal boundary structures. Mechanisms and strategies that enable self-organization at Spotify are related to effective sharing of the codebase, achieving alignment, networking and knowledge sharing, and are described to guide other companies in their efforts to scale autonomy. © 2023 The Author(s)

The COVID-19 outbreak has admittedly caused interruptions to production, transportation, and mobility, therefore, having a significant impact on the global supply and demand chain's well-functioning. But what happened to companies developing digital services, such as software? How has the enforced Working-From-Home (WFH) mode impacted their ability to deliver software, if at all? This article shares our findings from monitoring the WFH during 2020 in an international software company with engineers located in Sweden, the USA, and the UK. We analyzed different aspects of productivity, such as developer job satisfaction and well-being, activity, communication and collaboration, efficiency and flow based on the archives of commit data, calendar invites, Slack communication, the internal reports of WFH experiences, and 30 interviews carried out in April/May and September 2020. We add more objective evidence to the existing COVID-19 studies the vast majority of which are based on self-reported productivity from the early months of the pandemic. We find that engineers continue committing code and carrying out their daily duties, as their routines adjust to “the new norm”. Our key message is that software engineers can work from home and quickly adjust their tactical approaches to the changes of unprecedented scale. Further, WFH has its benefits, including better work-life balance, improved flow, and improved quality of distributed meetings and events. Yet, WFH is not challenge free: not everybody feels equally productive working from home, work hours for many increased, while physical activity, socialization, pairing and opportunities to connect to unfamiliar colleagues decreased. Information sharing and meeting patterns also changed. Finally, experiences gained during the pandemic will have a lasting impact on the future of the workplace. The results of an internal company-wide survey suggest that only 9% of engineers will return to work in the office full time. Our article concludes with the InterSoft's strategy for work from anywhere (WFX), and a list of useful adjustments for a better WFH. © 2022 The Author(s)

Requirements are key artefacts to describe the intended purpose of a software system. The quality of requirements is crucial for deciding what to do next, impacting the development process’ effectiveness and efficiency. However, we know very little about the connection between practitioners’ perceptions regarding requirements quality and its impact on the process or the feelings of the professionals involved in the development process. Objectives: This study investigates: i) How software development practitioners define requirements quality, ii) how the perceived quality of requirements impact process and stakeholders’ well-being, and iii) what are the causes and potential solutions for poor-quality requirements. Method: This study was performed as a descriptive interview study at a sub-organization of a Nordic bank that develops its own web and mobile apps. The data collection comprises interviews with 20 practitioners, including requirements engineers, developers, testers, and newly employed developers, with five interviewees from each group. Results: The results show that different roles have different views on what makes a requirement good quality. Participants highlighted that, in general, they experience negative emotions, more work, and overhead communication when they work with requirements they perceive to be of poor quality. The practitioners also describe positive effects on their performance and positive feelings when they work with requirements that they perceive to be good. © 2023, The Author(s), under exclusive license to Springer Nature Switzerland AG.

In early 2020, the Covid-19 pandemic forced employees in tech companies worldwide to abruptly transition from working in offices to working from their homes. During two years of predominantly working from home, employees and managers alike formed expectations about what post-pandemic working life should look like. Many companies are experimenting with new work policies that balance employee- and manager expectations regarding where, when and how work should be done in the future. In this article, we gather experiences of the new trend of remote working based on the synthesis of 22 company-internal surveys of employee preferences for WFH, and 26 post-pandemic work policies from 17 companies and their sites, covering 12 countries in total. Our results are threefold. First, through the new work policies, all companies formally give employees more flexibility regarding working time and location. Second, there is a great variation in how much flexibility the companies are willing to yield to the employees. The paper details the different formulations that companies adopted to document the extent of permitted WFH, exceptions, relocation permits and the authorisation procedures. Third, we document a change in the psychological contract between employees and managers, where the option of working from home is converted from an exclusive perk that managers could choose to give to the few, to a core privilege that all employees feel they are entitled to. Finally, there are indications that as the companies learn and solicit feedback regarding the efficiency of the chosen strategies, we will see further developments and changes in the work policies concerning how much flexibility to work whenever and from wherever they grant. Through these findings, the paper contributes to a growing literature about the new trends emerging from the pandemic in tech companies and spells out practical implications onwards. © 2022 The Author(s)

Internet of Things (IoT) is a growing technology that relies on connected ‘things’ that gather data from peer devices and send data to servers via APIs (Application Programming Interfaces). The design quality of those APIs has a direct impact on their understandability and reusability. This study focuses on the linguistic design quality of REST APIs for IoT applications and assesses their linguistic quality by performing the detection of linguistic patterns and antipatterns in REST APIs for IoT applications. Linguistic antipatterns are considered poor practices in the naming, documentation, and choice of identifiers. In contrast, linguistic patterns represent best practices to APIs design. The linguistic patterns and their corresponding antipatterns are hence contrasting pairs. We propose the SARAv2 (Semantic Analysis of REST APIs version two) approach to perform syntactic and semantic analyses of REST APIs for IoT applications. Based on the SARAv2 approach, we develop the REST-Ling tool and empirically validate the detection results of nine linguistic antipatterns. We analyse 19 REST APIs for IoT applications. Our detection results show that the linguistic antipatterns are prevalent and the REST-Ling tool can detect linguistic patterns and antipatterns in REST APIs for IoT applications with an average accuracy of over 80%. Moreover, the tool performs the detection of linguistic antipatterns on average in the order of seconds, i.e., 8.396 s. We found that APIs generally follow good linguistic practices, although the prevalence of poor practices exists.

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. © 2022 The Authors

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 artifacts. 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 analyzing two industrial cases and 31 open-source systems from Apache Foundation. Method: We analyzed 144,476 code TDIs (35,372 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.