APR 07, 2015 07:41 AM
What Do We Know about Software Development in Startups?
By Carmine Giardino, Michael Unterkalmsteiner, Nicolò Paternoster, Tony Gorschek, and Pekka Abrahamsson
Startups are newly created companies with little or no history of facing high volatility in technologies and markets. In the US alone, 476,000 new businesses are established each month, accounting for nearly 20 percent of job creation. As such, startups are an important factor in the economy.
However, the environment of startups is dynamic, unpredictable, and even chaotic, forcing entrepreneurs to act quickly, fail fast, and learn faster to land a market niche and acquire a sustainable income. Sixty percent of startups don’t survive the first five years, and 75 percent of venture capital funded startups fail. Most of this is due to the high risk of startups, missed market windows, and other business reasons. To what extent engineering practices impact this high failure rate is still unknown given the premature state of research.
We present a detailed investigation and collection of all known empirical software engineering sources related to startups and their engineering practices, as well as an analysis of how accurate and reliable this available evidence is. We see this as a first critical step into a largely unknown area—the world of software engineering practices in startups.
What is a startup, anyway?
In the past, the term “startup” had different meanings. Looking at the recurrent themes adopted by researchers and practitioners, a startup is a small company exploring new business opportunities, working to solve a problem where the solution isn’t well known and the market is highly volatile.
Being newly founded does not in itself make a company a startup. High uncertainty and rapid evolution are the two key characteristics for startups retrieved by the studies, which better differentiate them from more established companies. We retrieved and evaluated empirical evidence by using the systematic mapping study approach.
Startup software development
“Done is better than perfect” and “move fast and break things” are slogans you might read when entering a startup workspace. What stands behind those slogans is a summary of more than 200 working practices. We reviewed these to point out where gaps exist and future development and research are warranted.
Process management is agile, evolutionary, and opportunistic
Process management represents all the engineering activities used to manage product development in startups. Because the flexibility to accommodate frequent changes is essential in the startup context, high uncertainty and rapid evolution are the two key characteristics for startups.
Agile methodologies have been considered the most viable process—they embrace change, allowing development to adapt to the business strategy. Fast release with an iterative and incremental approach shortens the lead time from idea conception to production with fast deployment.
A variant to agile is the lean methodology, which advocates the identifi¬cation of the riskiest parts of a software business and provides a minimum viable product to systematically test and plan modi¬fication for the next iteration. In this regard, prototyping is essential to shorten the time to market.
To allow better prototyping activities, evolutionary workflows are needed to implement “soft-coded” solutions in the fi¬rst phases until the optimal solution is found. Despite the number of methodologies that embrace fast prototyping in development, none of the processes are strictly followed by startups.
Yet, the uncertainty and fast-changing needs of startups drive them to opportunistically tailor minimal process management to their short-term objectives and adapt to the fast-paced learning process of their users to address market uncertainty.
Startups are under constant pressure to rapidly demonstrate that they’re developing a solution that addresses a real problem. They’re constantly optimizing the problem/solution. To achieve it, startups must discover the real needs of their fi¬rst customers, testing business speculations only by defining a minimal set of functional requirements.
Several authors acknowledge the importance of involving the customer/user in the process of eliciting the effort for each story. However, polishing requirements that address an unsolicited need are a waste of effort.
Test the problem
Requirements elicitation methods are moving toward testing the problem and understanding if the solution ¬fits real needs before the product goes to market (the so-called customer development process).
In the startup context, customers often steer requirements, and developers must be ready to embrace change from day one. The use of architecture and design patterns to make features modular and independent is crucial when functionality is continuously updated or removed.
Therefore, employing architectural practices and frameworks that enable easy extension of the design can dramatically benefit the alignment between the product and market uncertainty. This requires some upfront effort but can prevent the growth of product complexity.
Scientific evidence also points to the advantages of constant code refactoring. Reimplementing the whole system might be costly and risky if it must be immediately scalable to a growing number of users.
Bringing value to customers
Therefore, some quality assurance is needed for the functionality that brings the most value to customers. The use of ongoing customer acceptance through focus groups made up of early adopters can provide a time-ef¬ficient way to discover major bugs. But solutions are still scarce for easily accessible automated testing frameworks and the more practical empowerment of team members represents the main viable strategy for enhancing performance and success.
The team must be able to absorb and learn from trial and error quickly enough to adapt to new emergent practices. Working on innovative products requires creativity—an ability to adapt to new roles and face new challenges every day, working overtime if necessary.
Indeed, in building a startup company, the team needs expertise to counterbalance its lack of resources. In addition, having previous experience in similar business domains and exhibiting entrepreneurial characteristics (courage, enthusiasm, commitment, leadership) are important parts of a startup employee’s skillset.
Nevertheless, the absence of structure might hinder important activities, such as sharing knowledge and team coordination, especially when the company grows. In this case, collocation is essential to facilitate informal communication and close interactions between team members.
No worries about legacy software
Startups can take advantage of the newest technologies and development tools without having to worry about legacy or previous working experiences. But the selection of a technology requires some domain- or product-specific requirements, which are typically unknown in the early stages.
In general, startup employees prefer using those technologies that can quickly accommodate change in the product and its management. Examples include general-purpose infrastructures, such as configuration management, problem reporting, tracking, and planning systems, and scheduling and notification systems.
Easy-to-implement tools, such as whiteboards and technologies that can handle fast-paced changing information, will lower a startup’s training and maintenance costs. To mitigate the lack of resources, startups often appear to take advantage of open source solutions when possible, which also give them access to a large pool of evaluators and evolving contributions.
Startup companies seek to generate revenue and obtain funding to continue the development, which means that software quality isn’t their most critical concern. To quickly validate the product, they tend to use agile and lean methods in an ad hoc manner.
Evidence suggests that engineering activities must be tailored to the startup context to allow flexibility and reactiveness in development workflows. Decision makers in startups confront continuous unpredictability; the relationship between cause and effect can only be perceived in retrospect.
Applying rigorous methodologies to control development activities isn’t effective because no matter how much time is spent on analysis, it isn’t possible to identify all the risks or accurately predict what practices are required to develop a product.
Learning from previous failures
On the other hand, flexible and reactive methods designed to stimulate customer feedback increase the number of perspectives and solutions available to decision makers.
Developers need the freedom to choose activities quickly, stop immediately when the results are wrong, ¬ x the approach, and learn from previous failures. In line with the lean startup movement, we would expect methodologies and techniques tailored from common agile practices to specific startups’ cultures and needs; failures should be completely acceptable or even preferred in favor of a faster learning process.
Reported common practices, which ride the wave of rapidly evolving technologies and markets, are as follows:
• use of well-known frameworks to quickly change the product according to market needs;
• use of evolutionary prototyping and experimentations via existing components;
• ongoing customer acceptance through early adopters’ focus groups;
• continuous value delivery, focusing on core functionalities that engage paying customers; and handle fast-paced, changing information.
Today’s startups are at the forefront of applying new technologies in practice. The growing startup phenomenon opens uncharted opportunities as well as challenges in research.
“Startuppers” need more transferable and reliable results concerning the diversity of context and viewpoints in the adoption of practices dealing with high uncertainty.
The full version of this article appeared in the January issue of ComputingEdge. To sign up for this free monthly digest of computing content, visit http://www.computer.org/computingedge.
Computing Now Blogs
by Keith Peterson
A Cloud Blog: by Irena Bojanova
The Clear Cloud: by STC Cloud Computing
Computing Careers: by Lori Cameron
Enterprise Thinking: by Josh Greenbaum
The Doctor Is In: Dr. Keith W. Vrbicky
NealNotes: by Neal Leavitt
Chasing Pixels - Finding Gems: by Jon Peddie
Internet Of Things
Sensing IoT: by Irena Bojanova