machine learning

Learning from agile software development

Self-organized Learning in Software Factory: Experiences and Lessons Learned

What Can Software Startuppers Learn from the Artistic Design Flow? Experiences, Reflections and Future Avenues

Why Early-Stage Software Startups Fail: A Behavioral Framework

Software startups are newly created companies with little operating history and oriented towards producing cutting-edge products. As their time and resources are extremely scarce, and one failed project can put them out of business, startups need effective practices to face with those unique challenges. However, only few scientific studies attempt to address characteristics of failure, especially during the early-stage. With this study we aim to raise our understanding of the failure of early-stage software startup companies. This state-of-practice investigation was performed using a literature review followed by a multiple-case study approach. The results present how inconsistency between managerial strategies and execution can lead to failure by means of a behavioral framework. Despite strategies reveal the first need to understand the problem/solution fit, actual executions prioritize the development of the product to launch on the market as quickly as possible to verify product/market fit, neglecting the necessary learning process.

Software development in startup companies: A systematic mapping study

Context: Software startups are newly created companies with no operating history and fast in producing cutting-edge technologies. These companies develop software under highly uncertain conditions, tackling fast-growing markets under severe lack of resources. Therefore, software startups present a unique combination of characteristics which pose several challenges to software development activities. Objective: This study aims to structure and analyze the literature on software development in startup companies, determining thereby the potential for technology transfer and identifying software development work practices reported by practitioners and researchers. Method: We conducted a systematic mapping study, developing a classification schema, ranking the selected primary studies according their rigor and relevance, and analyzing reported software development work practices in startups. Results: A total of 43 primary studies were identified and mapped, synthesizing the available evidence on software development in startups. Only 16 studies are entirely dedicated to software development in startups, of which 10 result in a weak contribution (advice and implications (6); lesson learned (3); tool (1)). Nineteen studies focus on managerial and organizational factors. Moreover, only 9 studies exhibit high scientific rigor and relevance. From the reviewed primary studies, 213 software engineering work practices were extracted, categorized and analyzed. Conclusion: This mapping study provides the first systematic exploration of the state-of-art on software startup research. The existing body of knowledge is limited to a few high quality studies. Furthermore, the results indicate that software engineering work practices are chosen opportunistically, adapted and configured to provide value under the constrains imposed by the startup context.

Towards Abstraction and Automation in Software Engineering

Novel software development approaches are embracing abstraction and automation techniques. It is claimed that abstraction and automation techniques increase the productivity, improve the reusability and lower the complexity of the projects. In this study we address these new frontiers of software development by investigating on one novel proposal, namely the Ball. The Ball is an information ecosystem for authorised information containing web content, digital content as well as service development and integration. It is claimed to improve the reusability, productivity and security of software development while lowering the complexity. While improving the software developer’s productivity it should produce smaller and more reasonable software systems, leading to a better reusability and a shorter learning phase for new developers. Up to now there exists no evidence to support these claims. In this study we analyse the Ball ecosystem from multiple perspectives. We compare it to related approaches in order to find its advantages and disadvantages. In order to provide empirical data we replicated a study where a mobile information system was developed using three different technologies. The results of this study show that the Ball ecosystem has the potential to improve the productivity of software development. However, it

A Simultaneous, Multidisciplinary Development and Design Journey - Reflections on Prototyping

This paper proposes a wayfaring approach for the early concept creation stage of development projects that have a very high degree of intended innovation and thus uncertainty. The method is supported by a concrete game design example involving the development of a tangible programming interface for virtual car racing games. We focus onto projects that not only have high degrees of freedom, for example in terms of reframing the problem or iterating the final project vision, but are also complex in nature. For example, these can be projects that allow for the exploration and exploitation of unknown unknowns and serendipity findings. Process wise we are primarily focusing onto the early stage that precedes the requirement fixation, which we see as more dynamic and evolutionary in nature. The core conceptual elements that we have derived from the development experiences are: simultaneous prototyping in multiple disciplines (such as computer science, electronics and mechanics and engineering in general, abductive learning based on the outcome of rapid cycles of designing, building and testing prototypes (probing), and the importance of includingall the involved disciplines (knowledge domains) from the beginning of the project on.

What leads developers towards the choice of a JavaScript framework?

Context: The increasing popularity of JavaScript (JS) has lead to a variety of frameworks that aim to help developers to address programming tasks. However, the number of JS Frameworks (JSF) has risen rapidly to thousands and more. It is difficult for practitioners to identify the frameworks that best fit to their needs and to develop new frameworks that fit such needs. Existing research has focused in proposing software metrics for the frameworks, which do not carry a high value to practitioners. While benchmarks, technical reports, and experts' opinions are available, they suffer the same issue that they do not carry much value. In particular, there is a lack of knowledge regarding the processes and reasons that drive developers towards the choice. Objective: This paper explores the human aspects of software development behind the decision-making process that leads to a choice of a JSF. Method: We conducted a qualitative interpretive study, following the grounded theory data analysis methodology. We interviewed 18 participants who are decision makers in their companies or entrepreneurs, or are able to motivate the JSF decision-making process. Results: We offer a model of factors that are desirable to be found in a JSF and a representation of the decision makers involved in the frameworks selection. The factors are usability (attractiveness, learnability, understandability), cost, efficiency (performance, size), and functionality (automatisation, extensibility, flexibility, isolation, modularity, suitability, updated). These factors are evaluated by a combination of four possible decision makers, which are customer, developer, team, and team leader. Conclusion: Our model contributes to the body of knowledge related to the decision-making process when selecting a JSF. As a practical implication, we believe that our model is useful for (1) Web developers and (2) JSF developers.

Time for AI (Ethics) Maturity Model Is Now

There appears to be a common agreement that ethical concerns are of high importance when it comes to systems equipped with some sort of Artificial Intelligence (AI). Demands for ethical AI are declared from all directions. As a response, in recent years, public bodies, governments, and universities have rushed in to provide a set of principles to be considered when AI based systems are designed and used. We have learned, however, that high-level principles do not turn easily into actionable advice for practitioners. Hence, also companies are publishing their own ethical guidelines to guide their AI development. This paper argues that AI software is still software and needs to be approached from the software development perspective. The software engineering paradigm has introduced maturity model thinking, which provides a roadmap for companies to improve their performance from the selected viewpoints known as the key capabilities. We want to voice out a call for action for the development of a maturity model for AI software. We wish to discuss whether the focus should be on AI ethics or, more broadly, the quality of an AI system, called a maturity model for the development of AI systems.

Implementing AI Ethics in a Software Engineering Project-Based Learning Environment - The Case of WIMMA Lab

Key Challenges in Software Startups Across Life Cycle Stages

Software startups are challenging endeavours, with various road blocks on their path to success. The current understanding of the challenges that software startups may encounter is very limited. In this paper, we use the research framework of learning and product development stages to analyse the key challenges that software startups have to deal with at different life cycle stages, from problem definition to solution validation and from concept to mature product. Based on an analysis of the empirical data collected by a large survey of 4100 startups, we find out that what perceived as biggest challenges by software startups do vary across different life cycle stages. Building product is the biggest obstacle for software startups, even though its significance decreases when the learning focuses of the startups move from problem to solution and their products mature. Business related challenges such as customer acquisition and scaling are more noticeable at the later stages. Our study raises the awareness of these challenges and suggests to tackle right challenges at the right time.

Minimum Viable Product or Multiple Facet Product? The Role of MVP in Software Startups

Minimum viable product (MVP) is the main focus of both business and product development activities in software startups. We empirically explored five early stage software startups to understand how MVP are used in early stages. Data was collected from interviews, observation and documents. We looked at the MVP usage from two angles, software prototyping and boundary spanning theory. We found that roles of MVPs in startups were not fully aware by entrepreneurs. Besides supporting validated learning, MVPs are used to facilitate product design, to bridge communication gaps and to facilitate cost-effective product development activities. Entrepreneurs should consider a systematic approach to fully explore the value of MVP, as a multiple facet product (MFP). The work also implies several research directions about prototyping practices and patterns in software startups.