Response Article: In response to “Startups and Development Methodologies” by s0969755

# Introduction

This article is a response to “Startups and Development Methodologies” by s0969755 [1], which explores aspects of software development in early stage technology start-up companies. The article discusses challenges which face small start-up organisations when attempting to implement best practice methodologies or software engineering techniques which result from the limited resources available to the company, drawing on personal experience and anecdotal data gathered from examining large successful start-ups Google and Facebook.

The author presents the idea that start-ups which eschew a development methodology (or adopt an unstructured, laissez faire approach to development) are likely to suffer from a lack of discipline or rigour in software engineering. The author suggests that such organisations may be prone to making ad-hoc additions or modifications to their software without proper regard to the sustainability of the development, and that this may ultimately undermine the goals of the organisation. The author concludes that the adoption of Agile processes (with some exceptions due to pragmatism, such as working week restrictions) may cause the organisations software development to incur some short term costs, but that in the long term will lead to more sustainable engineering practices.

# I Agree With Most of the Article

I broadly agree with most of the ideas presented in the article, and think that some of the concepts explored would benefit from additional context about the role of software engineering in a technology based start-up environment. By drawing from the ideas presented in the Lean Startup [2] methodology, I will consider what the ultimate purpose of a start-up is and how by working backwards from this, best practice solutions can be derived. In this response I will expound on the ideas presented by the original author, augmenting them by examining software development in the specific context of what separates a start-up from a regular software project, and justifying why Agile and Lean practices are appropriate given these contextual constraints.

Specifically, I intend to examine the increased emphasis on gathering metrics and implementing analytics support in software, and examining the role these metrics play in validated learning, (which may lead to pivots), and consequently how to sustainably develop when aiming for a moving target. Additionally, I will briefly present an argument that a start-up need not diverge from established Agile practices such as the 40-hour week merely as a reaction to its constrained resources; it should instead ruthlessly focus on how to meet its current in the most effective (i.e., globally efficient) manner possible. Similarly to the author of the original article, I will conclude that automated testing, continuous deployment and a disciplined approach to development is crucial to give a technology based start-up the best chance of success.

# What Is A Start-Up?

A start-up, as defined by Steve Blank [3], is a “temporary organisation designed to search for a repeatable and scalable business model”. This is a useful definition as it illustrates that a start-up is not simply a small version of a large and established company, it is instead a transient state an organisation goes through when attempting to determine what the organisation is going to do (i.e., what value or service will it provide and monetize). The Lean Startup is a methodology advocated by Eric Ries for helping a start-up organisation to reduce risk by increasing the rate at which the search for a business model can progress, by emphasising the principles of rapid iteration cycles, minimum viable products and “validated learning”.

For technology companies, this will typically result in engagement with potential customers in the marketplace, which will result in the formation of hypotheses about problems these customers face and what viable solutions may be. The organisation will then engage in rapid development of prototypes designed to prove or disprove the hypothesis. Depending on the result, the hypothesis may be reformulated or refined (or discarded entirely) to optimise the produce for different categories of customer engagement. These types of engagement may include activation (did the customer use the product long enough to sign up for an account, or some similar definition?), retention (did the customer come back to the product the next hour/day/week?), virality (did the customer directly or indirectly refer another customer?) or monetization (did the customer pay us?). Depending on the performance of the product in these key metrics, the organisation may choose to persist (further develop the original hypothesis and product) or pivot (change the initial hypothesis in response to lessons learned). The decision to pivot may necessarily result in substantial changes to the implementation of the software.

# Special Requirements For Software Development In A Start-Up

The author of the original article describes the requirement for short release cycles and the frequent phenomenon of changing requirements, but does not go into detail explaining what the purpose of short release cycles are or why rapid requirement changes occur (and the technical implications of both of these). This section will consider in more detail the special requirements placed on the software engineering team in a technology start-up.

It follows from the previous section that the software in a start-up must be developed with a focus on implementing mechanisms for collecting metrics on customer behaviour such that conclusions can be drawn on the hypothesis. The software should ideally be delivered to customers in a format such that it can be rapidly modified and redeployed in response to lessons learned from the metrics gathered. The software should be engineered to be flexible and malleable, such that in the highly likely event of software changes necessitated by either a decision to pivot or persist, the software architecture does not present an unreasonable burden to change.

The implication from these constraints is that the robustness of both the deployment infrastructure and the metrics gathering software is critical. The longer the cycle of forming a hypothesis, implementing the software, gathering metrics from customers, and analysing the metrics to draw conclusions on the hypothesis is, the riskier for the startup. It is then paramount that the deployment infrastructure should not present any unnecessary delay in delivering new iterations of the product to customers. The ideal platform to satisfy this requirement is the web, as new versions of the application can be deployed instantaneously. Rapid deployment of mobile applications is also possible, although with some potential delays potentially imposed by the vendor (such as the iOS App Store acceptance process). A worse case scenario for application of the Lean methodology would be where this is a natural barrier to rapid development cycles, such as the software being delivered on a physical media or embedded device,  due to inherently longer iteration cycles.

Irrespective of the target platform or environment, the method of delivery must be robust and reliable due to the emphasis on short release cycles; this implies a hard requirement for solid engineering in the deployment process, and resources expended here (in terms of automated testing, paired programming, etc.) to ensure a solid foundation will likely be repaid with interest over the lifetime of the start-up.

In addition to a requirement for a solid deployment infrastructure, it is critical that metrics gathering mechanisms be reliable. The gathering of metrics from the usage of the produce forms a crucial component of hypothesise-build-learn iteration cycle, which is the backbone of the Lean methodology. If the mechanism for collecting metrics is not reliably, the team cannot have faith in the lessons they have learned from an implementation of a product iteration. Similarly to the deployment infrastructure, this suggests placing a high priority on expending the resources required to employ software engineering best practices to develop the metrics systems. As well as the requirement for gathering metrics reliably, the organisation must be able to analyse and process these metrics in order to come to the correct conclusion to inform the hypothesis for the next product iteration. This calls for investing resource in the development of robust tooling for metrics analysis.

This section has focussed on constraints that face start-up organisations which do not necessarily affect established organisations as critically. However, start-up organisations are typically resource constrained due to lack of human resources and funding. Therefore it is important to balance these additional requirements to be able to effectively deploy and learn from rapid iteration cycles with the start-up resource scarcity; the next section will consider how a start-up can work to optimise its development given these constraints.

# Organisational And Methodological Considerations For Resource Management

A points in the original article with which I do not necessarily agree is the contention that as a natural consequence of limited resources, a start-up should discard established Agile practice such as paired programming and working week hour limitations. These principles exist because they are considered beneficial to producing software in a sustainable manner, and should not be hastily surrendered if possible. This section considers some methodological measures a start-up can take to make best use of their resources.

As highlighted in the previous section, a start-up depends on its ability to iterate and learn rapidly; these are achieved by a robust deployment infrastructure and metrics gathering and analysis tools. These requirements are potentially expensive to implement and maintain, and typically do not form part of the value proposition of the start-up (assuming the start-up does not, upon recognition of the sophistication of its internal tooling, pivot into becoming a deployment or metrics solutions provider!). In recognition of this, various third party tooling providers exist to fill this niche. Platform As A Service (PAAS) companies such as Heroku can simplify deployment for web based start-ups to free them of the requirement to manage deployment nuances or maintain infrastructure, and metrics services such as Google Analytics, Kontagent, Flurry, etc., can remove the burden of metrics gathering from the start-up, freeing its resources to focus on the problem at hand.

When testing a hypothesis, some system implementation may need to be written. It may seem obvious that only the minimum solution which allows the hypothesis to be tested should be written, but when in the heat of the moment developing software, it can be tempting to build a fully-featured solution, which elegantly and generally solves the problem but may ultimately be wasteful if the hypothesis is proved incorrect. By ruthlessly focussing on implementing the minimal solution required prove or disprove some hypothesis about the product, resources can be most effectively channeled. For example, in a web or mobile start-up, someone may hypothesise that the addition of a feature might increase user engagement in the product. To test this, the feature could be implemented and the resulting user engagement tested. However, a more resource efficient way to test this hypothesis may be to determine some proxy for user engagement, and test for that. A link to the new feature could be added, which does not link to the feature itself but instead allows the user to sign-up to be informed when the feature is added. By measuring the number of clicks and sign-ups, the potential engagement of the feature can be determined and the hypothesis tested for a low cost. If the feature appears to be engaging, it may then be implemented, but if not then the time saved may be significant.

In addition to writing as few features as possible to validate a hypothesis, other constraints such as targeting a single platform may be appropriate. For example, a mobile application may elect to only target iOS rather than Android (for example); this is a valid strategy, as the purpose of a start-up is to search for a scalable business model. Scaling the implementation to multiple platforms should not be attempted until the business case for the product is validated.

When developing features, it may be beneficial to use as high a level language as possible (with respect to any established performance constraints). This will likely allow the most rapid iteration, which is crucial for the start-up. Even considering performance concerns such as scalability, it may still be a better idea to develop with a high level language; again, this is due to the nature of the start-up as a mechanism for searching for a scalable business model, not a scalable technical solution. When scaling technically is required, this is a very string indication that the start-up has validated its business model! As the author of the original article observes, this may have maintenance implications for the software team when the company has become established, such as Facebook’s problems scaling PHP and Twitter’s well publicised switch to the JVM after proving its business model on Ruby [5].

By taking advantage of existing tooling where available to make the best use of limited development resources, the start-up software engineering team will iteratively build towards a complete implementation of a solution. As the author of the original article suggests, this may result in an accumulation of partial implementations, or hacked in features. It is important to keep on top of this technical debt as it accumulates. This can be achieved by using standard refactoring [4] techniques, relying on automated tests to ensure that the implementation remains functional as it is refactored; this may be especially required if the implementation is created in a high level dynamic language amenable to rapid prototyping.

By a combination of leveraging existing tools and solutions where possible, by only implementing the minimum amount of features necessary to prove or disprove a hypothesis, and by selecting an appropriate language and target environment amenable to rapid iteration, a start-up team ensure that the cost of development is minimised. By doing so, it can then invest the resources it has in best established Agile software engineering best-practices such as paired programming and the 40-hour week; this has other benefits, such as building a team of generalists who have a shared ownership of the software, and promoting sustainable development.

# Conclusion

In this article I have presented various ideas and concepts which I feel help to augment the discussion presented in the “Startups and Development Methodologies” by s0969755 [1]. By considering the purpose of a start-up organisation, I have examined the specific requirements for a start-up which differentiates it from an ordinary organisation; a technical start-up must equip itself with the tools to rapidly experiment, iterate and learn. I have explored the strategies by which a start-up can make the most effective use of its limited resources, and in doing so disagree with the author of the original article on the specific contention that it is necessary to discard Agile best practices such as the 40-hour working week. Instead, by adopting a methodology such as Lean [2] which advocates a ruthless and disciplined focus on reducing risk by rapid iteration, and by best exploiting available tools and existing solutions, a start-up can optimise the use of its constrained resources.

# References

[1] s0969755. “Startups and Development Methodologies”, SAPM Blog. URL: https://blog.inf.ed.ac.uk/sapm/2014/02/14/startups-and-development-methodologies/ (Last checked 22/2/2014)

[2] Ries, Eric. The lean startup: How today’s entrepreneurs use continuous innovation to create radically successful businesses. Random House LLC, 2011.

[3] Blank, Steve. “Search versus execute.” URL: http://steveblank.com/2012/03/05/search-versus-execute/ (Last checked 22/2/2014)

[4] Fowler, Martin. “Refactoring: improving the design of existing code.” Addison-Wesley Professional, 1999.

[5] Venners, Bill. “Twitter on Scala.” URL: https://www.artima.com/scalazine/articles/twitter_on_scala.html (Last cheched 22/2/2014)