Saab AB developed software that had a defect that manifested itself only after months of continuous system use. After years of customer failure reports, the defect still persisted, until Saab developed failure replication based on visual GUI testing. © 1984-2012 IEEE.

Software architects are key assets for successful development projects. However, not much research has investigated the challenges they face in large-scale distributed projects. So, researchers investigated how architects at Ericsson were organized, their roles and responsibilities, and the effort they spent guarding and governing a large-scale legacy product developed by teams at multiple locations. Despite recent trends such as microservices and agile development, Ericsson had to follow a more centralized approach to deal with the challenges of scale, distribution, and monolithic architecture of a legacy software product. So, the architectural decisions were centralized to a team of architects. The team extensively used code reviews to not only check the code's state but also reveal defects that could turn into maintainability problems. The study results also suggest that the effort architects spend designing architecture, guarding its integrity and evolvability, and mentoring development teams is directly related to team maturity. In addition, significant investment is needed whenever new teams and locations are onboarded.

The engineering of complex software systems is often the result of a highly collaborative effort. However, collaboration within a multinational enterprise has an overlooked legal implication when developers collaborate across national borders: It is taxable. In this article, we discuss the unsolved problem of taxing collaborative software engineering across borders.

Requirements engineering focuses on good specification practices but has yet to find working solutions for effective requirements communication. Inadequate communication and tacit assent to a demanding customer's requests make it hard to fully understand a project's requirements. A negotiation process, called handshaking with implementation proposals, has been used to communicate requirements effectively—even in situations where almost no written requirements exist and where distance separates the customer from developers. Handshaking is an efficient, flexible technique that uses architectural options to understand requirements, to make implementation decisions that create value, and to establish the foundation for a stable project. This article describes the communication challenges, solutions, and lessons learned in developing the handshaking process and applying it in industrial practice.

More than 64 countries and regions have, so far, developed COVID-19 contact-tracing apps to limit the spread of coronavirus. However, many experts and scientists cast doubt on the effectiveness of those apps. For each app, between a few hundred to a few thousand reviews have been entered by end-users in app stores. In this paper, we mine insights from the user reviews of contact-tracing apps of eight European countries to find out what end users think of COVID contact-tracing apps and the main problems that users have reported. IEEE

According to different reports, many recent software engineering graduates often face difficulties when beginning their professional careers, due to misalignment of the skills learnt in their university education with what is needed in industry. To address that need, many studies have been conducted to align software engineering education with industry needs. To synthesize that body of knowledge, we present in this paper a systematic literature review (SLR) which summarizes the findings of 33 studies in this area. By doing a meta-analysis of all those studies and using data from 12 countries and over 4,000 data points, this study will enable educators and hiring managers to adapt their education / hiring efforts to best prepare the software engineering workforce. IEEE

Test smells are poorly designed tests and negatively affect the quality of test suites and production code. We present the largest catalog of test smells, along with a summary of guidelines, techniques, and tools used to deal with test smells.

An impressive number of new startups are launched every day as a result of growing new markets, accessible technologies, and venture capital. New ventures such as Facebook, Supercell, Linkedin, Spotify, WhatsApp, and Dropbox, to name a few, are good examples of startups that evolved into successful businesses. However, despite many successful stories, the great majority of them fail prematurely. Operating in a chaotic and rapidly evolving domain conveys new uncharted challenges for startuppers. In this study, the authors characterize their context and identify common software development startup practices.

The product development environment facing most companies today requires a long-term perspective featuring the conception and development of long-term innovations. This can be hard when close quarter bottom-line results dominate. Without innovation, competitive advantages decrease over time. This is especially true for companies producing software-intensive systems. Software is becoming a large part of the competitive advantage of traditionally hardware-focused systems such as cars, robots, or power systems, where feature sets traditionally offered and controlled by hardware are transferred to software. As software's impact and influence grows, so do the possibilities for innovation and increasing the competitive advantage through software. Star Search is a lightweight innovation model based on best practices from innovation management literature as well as two industry cases. It employs face-to-face screening and idea refinement using heterogeneous audition teams. Star Search was developed in collaboration with, and subsequently piloted at, two companies. It has helped increase the long-term perspective of product development by increasing the level of new ideas that make it to product planning and development

Technology transfer, and thus industry-relevant research, involves more than merely producing research results and delivering them in publications and technical reports. It demands close cooperation and collaboration between industry and academia throughout the entire research process. During research conducted in a partnership between Blekinge Institute of Technology and two companies, Danaher Motion Saro AB (DHR) and ABB, we devised a technology transfer model that embodies this philosophy. We initiated this partnership to conduct industry-relevant research in requirements engineering and product management. Technology transfer in this context is a prerequisite: it validates academic research results in a real setting, and it provides a way to improve industry development and business processes

This article provides a taxonomy for risk-based testing that serves as a tool to define, tailor, or assess such approaches. In this setting, the taxonomy is used to systematically identify deviations between the requirements from public standards and the individual testing approaches.

In this position paper, we elaborate on the possibilities and needs to integrate Design Thinking into Requirements Engineering. We draw from our research and project experiences to compare what is understood as Design Thinking and Requirements Engineering considering their involved artifacts. We suggest three approaches for tailoring and integrating Design Thinking and Requirements Engineering with complementary synergies and point at open challenges for research and practice. IEEE

Software is becoming essential for most products, manufacturing processes, and back-office functions. The speed of delivering new features and refining the product is critical to remaining competitive. Software organizations may adopt continuous engineering practices to become more efficient. However, retrofitting an organization with a pipeline is challenging. Importantly, the most significant challenges and opportunities, are related to, but stem from outside the engineering realm and require rethinking customer relationships and business models. This paper presents a hierarchy of continuous engineering benefits and challenges. It is aimed to guide the adoption of continuous practices in an organization to determine the current and target level of adoption, given organizational context, ambitions, and domain constraints. IEEE

Software start-up failures are often explained with a poor business model, market issues, insufficient funding, or simply a bad product idea. However, inadequacies in software engineering are relatively unexplored and could be a significant contributing factor to the high start-up failure rate. In this paper we present the analysis of 88 start-up experience reports, revealing three anti-patterns associated with start-up progression phases. The anti-patterns address challenges of releasing the first version of the product, attracting customers, and expanding the product into new markets. The anti-patterns show that challenges and failure scenarios that appear to be business or market related are, at least partially, rooted in engineering inadequacies.

Software start-ups are new companies aiming to launch an innovative product to mass markets fast with minimal resources. However a majority of start-ups fail before realizing their potential. Poor software engineering, among other factors, could be a significant contributor to the challenges experienced by start-ups.

Very little is known about the engineering context in start-up companies. On the surface, start-ups are characterized by uncertainty, high risk and minimal resources. However, such characterization is not granular enough to support identification of specific engineering challenges and to devise start-up specific engineering practices.

The first step towards understanding on software engineering in start-ups is definition of the Start-up Context Map - a taxonomy of engineering practices, environment factors and goals influencing the engineering process. Goal of the Start-up Context Map is to support further research on the field and to serve as an engineering decision support tool for start-ups. 

In a world that depends increasingly on complex, critical, and intertwined systems, requirements engineering is crucial to developing and maintaining safety-critical systems (SCSs). Researchers studied the state of the art (through the literature) and the state of the practice (through in-depth interviews with practitioners) to discover what approaches are available for capturing, specifying, and communicating safety requirements throughout the SCS lifecycle and to determine the remaining challenges. © 2017 IEEE.

Competing for talents requires a conscious effort to offer an attractive workplace, which, until recently, involved increasing employee empowerment and engagement and offering opportunities for bottom-up innovation. Today, this is not sufficient, pushing tech companies to harmonize existing strategies with remote work.

Psychological safety is a precondition for learning and success in software teams. But what happens to psychological safety when work becomes remote? In this article, we explore how Norwegian software developers experienced remote work under the pandemic and after restrictions were waved and describe simple behaviors and attitudes related to psychological safety. We pay special attention to work arrangements in which team members alternate days in the office with days working remotely. Our key takeaway is that psychological safety is enabled by spontaneous interaction, which is easy to facilitate in the office and hard to facilitate remotely. Our findings lead us to recommend that team members align their work modes to increase chances for spontaneous interaction in the office while benefiting from the increased focus associated with working remotely. Author

In software engineering, the objective function of human decision makers might be influenced by many factors. Relying on historical data as the ground truth may give rise to systems that automate software engineering decisions by mimicking past suboptimal behavior. We describe the problem and offer some strategies. ©IEEE.

While in every organization corporate culture and history change over time, intentional efforts to identifyperformance problems are of particular interest when trying to understand the current state of an organization.The results of past improvement initiatives can shed light on the evolution of an organization, and represent,with the advantage of perfect hindsight, a learning opportunity for future process improvements. Weencountered the opportunity to test this premise in an applied research collaboration with the SwedishTransport Administration (STA), the government agency responsible for the planning, implementation andmaintenance of long-term rail, road, shipping and aviation infrastructure in Sweden.

This article presents an ecosystem that Ericsson developed to systematically practice large-scale reuse of microservices in a cloud-native context. We discuss how various ecosystem aspects, such as its continuous delivery mechanism, marketplace, and automated checking of design rules, facilitated the development and reuse of microservices across Ericsson. We also share lessons learned while developing the ecosystem including the initiatives related to the adoption of InnerSource practices for sustaining the ecosystem. 

The better-than-expected forced working from home (WFH) experiences coupled with investments enabling remote work during the pandemic motivated many employees to continue WFH occasionally, often, or entirely. Many organizations adjust their policies to increase flexibility as reported in numerous news outlets, articles, blogs, and channels dedicated to future workplace. The studies praise the flexibility given to individuals and the increase in the work-life balance but also warn about the alienation of staff members, decreased team cohesion and sense of belonging, as well as dilution of the corporate culture. This article systemizes a spectrum of emerging work arrangements for teams, including hybrid teams, partially aligned teams and, more importantly, variegated teams with fully aligned alternation of office presence. Our team typology is based on the practical insights from ‘Alpha,’ ‘InterSoft,’ Valtech, IBM, Brandwatch, and Ericsson and provides a nuanced vocabulary for organizations to start reasoning about the future work arrangements. IEEE

COVID-19 pandemic has irreversibly changed the attitude towards office presence. While previously remote workers were met with skepticism and distrust, today the same applies to companies prohibiting remote working. Albeit many workspaces are half empty. In this paper, we offer insights into the role of the office, corporate policies and actions regarding remote work in eight companies: Ericsson, Knowit, SpareBank 1 Utvikling, Spotify, Storebrand, Telenor, Company-X, Company-Y, and their sites in Sweden, Norway and the UK. Our findings are twofold. First, we found that companies indeed struggle with office presence and a large share of corporate space (35-67%) is underutilized. Second, we found that the main motivator for office presence is Connection and community, followed by Material offerings, Preference and Duty. Finally, we summarize actionable advice to promote onsite work, which is likely to help many other companies to rejuvenate life in their offices. IEEE

The new generation of software companies has revolutionized the way companies are designed. While bottom-up governance and team autonomy improve motivation, performance, and innovation, managing agile development at scale is a challenge. We describe how Spotify cultivates guilds to help the company share knowledge, align, and make collective decisions.

Staffing software projects with engineers from best-cost locations has become a commonality. However, distributed development remains practically challenging with many recurring problems, such as decreased productivity, low quality, and high unforeseen extra costs. One main underlying reason for these challenges is high employee turnover, although often overlooked. In developing locations such as India turnover is significantly large due to personal benefits from ‘job-hopping’. Why is turnover such a problem? Should companies stop sourcing to countries with high turnover or are there known remedies? This research puts turnover of software engineers in India in the spotlight and derives strategies to address it. We share experiences from two industrial cases, discuss important variables for portraying the actual turnover state and its negative impacts. Furthermore, we put forward ten recommendations for actively reducing turnover itself and lowering its negative consequences. IEEE

An offshore team's hourly costs took three years to become comparable with the in-house team's costs. Getting close to breaking even took five years. Learning costs due to offshore employee turnover were the primary cost factor to get under control.

Globalization of software work has become common in today's market. As part of cost-reduction strategies, many product-focused software companies started shipping their product development to insourcing and outsourcing offshore locations. Unfortunately, moving software products from one site to another isn't always a good business strategy for either the organization or the product. In this article, the authors discuss findings from studying software insourcing transfers at Ericsson, a large software product development company headquartered in Sweden. Their findings suggest that certain product, personnel, and process characteristics can facilitate the execution of an offshore insourcing transfer. On the basis of research conducted together with the company, they share a list of critical factors alleviating transfer difficulties and seven strategies facilitating transition of software work across sites.