Context: Software start-ups are emerging as suppliers of innovation and software-intensive products. However, traditional software engineering practices are not evaluated in the context, nor adopted to goals and challenges of start-ups. As a result, there is insufficient support for software engineering in the start-up context. Objective: We aim to collect data related to engineering goals, challenges, and practices in start-up companies to ascertain trends and patterns characterizing engineering work in start-ups. Such data allows researchers to understand better how goals and challenges are related to practices. This understanding can then inform future studies aimed at designing solutions addressing those goals and challenges. Besides, these trends and patterns can be useful for practitioners to make more informed decisions in their engineering practice. Method: We use a case survey method to gather first-hand, in-depth experiences from a large sample of software start-ups. We use open coding and cross-case analysis to describe and identify patterns, and corroborate the findings with statistical analysis. Results: We analyze 84 start-up cases and identify 16 goals, 9 challenges, and 16 engineering practices that are common among start-ups. We have mapped these goals, challenges, and practices to start-up life-cycle stages (inception, stabilization, growth, and maturity). Thus, creating the progression model guiding software engineering efforts in start-ups. Conclusions: We conclude that start-ups to a large extent face the same challenges and use the same practices as established companies. However, the primary software engineering challenge in start-ups is to evolve multiple process areas at once, with a little margin for serious errors.

/pdf/a-progression-model-of-software-engineering-goals-challenges-4gf3d1sdbm.pdf

A Progression Model of Software Engineering Goals, Challenges, and Practices in Start-Ups

The cloud computing paradigm introduces new possibilities and challenges for application design and deployment. On-demand resource provisioning, as well as resource and cost elasticity, need to be considered when realizing large-scale distributed applications for cloud environments. Current approaches do not sufficiently address the challenges of efficiently architecting and deploying cloud applications in a holistic manner and do not deal with the specific challenges encountered in cloud infrastructures. In this paper we introduce a methodology tackling the practical problems encountered when designing and deploying cloud applications. It enables the structured creation of cloud-native applications, addressing the complete application development lifecycle, from architectural design to concrete deployment topologies provisioned and executed on cloud infrastructure. By using iterative refinement and seamless provenance documentation of decisions made in the process, the methodology eases communication with relevant stakeholders and enables efficient design and deployment of distributed cloud applications.

/pdf/madcat-a-methodology-for-architecture-and-deployment-of-2x3qndd7eq.pdf

MADCAT: A Methodology for Architecture and Deployment of Cloud Application Topologies

This study empirically tackles the question of whether taking an outside-view approach, recommended for reducing the irrational behaviours associated with the planning fallacy, can also reduce the time underestimation, scope overload and over-requirement problems plaguing planning decisions in software development. Drawing on descriptive behavioural decision theory, this study examines whether the planning fallacy, a cognitive bias referring to the tendency of people to underestimate costs and overestimate benefits in evaluating a task to be performed, can provide a theoretical platform for mitigating irrational behaviours in the planning of software development projects. In particular, we argue that taking an outside-view approach in planning decisions for software development may have the same mitigating effects on time underestimation, scope overload and over-requirement it has been shown to have on cost underestimation and benefit overestimation. In an experiment investigating this argument, participants were randomly assigned to four groups by manipulating two outside-view mechanisms: reference information about past completion times present/absent and role perspective developer/consultant. After being presented with a to-be-developed software project, they were requested to estimate development times of various software features and to recommend which features to include within project scope given a fixed duration for the entire project. The results confirm that the three problems of time underestimation, scope overload and over-requirement are manifested in planning decisions for fixed-schedule software development projects. Moreover, the results show that these problems are mitigated, yet not eliminated, by presenting reference information about past completion times and by having a consultant role.

Can the outside-view approach improve planning decisions in software development projects?

Explaining over-requirement in software development projects: An experimental investigation of behavioral effects

Excessive software development: Practices and penalties

This paper examines the inevitable product feature creep, also known as requirements creep, from an engineering project manager's perspective. Feature creep is often the wildcard a project manager has to balance against resources, cost and schedule. After first describing the nature and sources of feature creep, the paper delves into the detrimental aspects of feature creep, some of which are non-intuitive and affect a project in subtle ways. Finally, the paper describes methods to defend a project against the negative aspects of feature creep and incorporate change in a constructive way. This rigorous look at feature creep should help any engineering project manager balance the factors that affect a project, resulting in a successful product release.

B. Elliott

Papers

Anything is possible: Managing feature creep in an innovation rich environment