Issue 20

Software Craftsmanship and Lean Startup

Alexandru Bolboacă
Agile Coach and Trainer, with a focus on technical practices
@Mozaic Works


The Lean Startup movement was a revolution in the startup world, although it started from a simple observation. The standard way to create a startup was until recently "Build, Measure, Learn":

  • An entrepreneur comes up with a product vision
  • After obtaining necessary financing, he/she builds the product according to the vision the product is tested on the market
  • If it is successful, awesome! If not, it is modified to be closer to the needs of real users.

The problem of this model is that at the time when the product is tested on the market, it was already built, meaning that money and effort were invested in it. From the technical point of view, the product was often rushed, the programmers worked under pressure and the code is difficult to change and full of bugs.

Steve Blank and Eric Ries came up with the idea to reverse this cycle and use "Learn, Measure, Build" instead:

  • An entrepreneur comes up with a product vision. The vision is turned into a set of hypothesis.
  • Each hypothesis is tested through an experiment. The result of the experiment is measurable and compared with the expectations defined in the hypothesis.
  • Once the hypothesis was validated, the solution can be developed and packaged in a product.

While the experiment can include the development of a working prototype for an application, it is not really necessary. The art is in defining the minimum investment to validate the hypothesis. The most common experiments, especially for online products, are "A/B testing": two possible implementations are competing and "voted" by potential users. The most popular is usually chosen as the winner.

On technical level, Lean Startup requires high agility due to working in an unknown environment, under discovery. If the standard product development model assumes that the vision, the current and future features are all known, in a lean startup the vision can modify depending on the market (through pivoting), features are discovered through experiments and the next requirements are often surprising.

Flickr is a classic example. Flickr is well known as the image storage service acquired by Yahoo. Their initial vision was to build a game called "Game Neverending" that had one feature allowing the player to add and share photos. The team realized after a while that the game was not well received, but the photo sharing feature was. They decided to focus on flickr.com and stop developing the game.

The Lean Startup litterature barely mentions the technical aspects. The authors had two reasons: the revolution had to start from the business side and they assumed programmers will know what technical practices to use.

Imagine though the context of many online startups today. Many of them deploy a new feature hundreds of times a day. Each deployment is either an A/B test or a validated feature.

This development rhythm requires programming skills such as:

  • Incremental thinking - splitting a large feature into very small ones that can be rapidly implemented in order to get fast feedback from the market
  • Automated testing - a combination of unit tests, acceptance tests, performance tests, security tests is necessary to rapidly validate any change in the code
  • Design open to change - with inflexible design, any change takes too long
  • Code easy to modify - following common coding guidelines, optimizing for readability and writing code easy to understand are essential for keeping a high development speed
  • Refactoring - the design will inevitably be closed to change in certain points. Fast refactoring is an essential skill to turn it into a design easy to change.

In addition to the technical practices, the proficient teams often use clear workflows that commonly include: monitoring, reversing to previous version when major bugs appear, validation gates before deployment etc.

Not all startups need to deploy hundreds of times a day. Sometimes it is enough to have a feedback cycle of under a week. The necessary programming skills are the same. The only difference is that the work can be split in larger increments.

If the link with Software Craftsmanship is not yet clear, let"s explore it some more. As we showed in the article on Software Craftsmanship [http://www.todaysoftmag.com/article/en/11/Software_Craftsmanship__404], the movement has appeared to allow reducing cost of change through applying known technical practices and through discovering new ones. Some of the practices we know and use today are:

  • Test Driven Development, to incrementally design a solution adapted to the problem and open to change
  • Automated testing, to avoid regressionsSOLID principles, design patterns and design knowledge to avoid closing the design to change
  • Clean Code to write code easy to understand
  • Refactoring to bring design back to the necessary level when it is unfit

When should a team working in a startup invest in such practices? The answer should be easy for anyone following the lean startup model: as long as you are beginning to discover the customers through experiments, there is no need to invest more time than necessary. The best experiments do not require implementation. If code is required after all, the most important thing is to write it as fast as possible, even though mistakes can be made.

Once a feature was validated, the code needs to be written, or re-written, so that it is easy to modify. The risk is otherwise to benefit too late from the learnings of the experiments.

It is important to mention that developers who practiced these techniques for long enough can implement faster when using them. This is the Software Craftsmanship ideal: develop the skills so well so that they become the implicit and the fastest way to build software, especially when the development speed is very important.


Lean Startup needs Software Craftsmen. The best experiments require zero code. Sometimes, code is needed. A Software Craftsman is capable to implement them fast and without adding problems.

If, in the discovery phase, practices such as TDD, automated testing or refactoring can be skipped, the implementation phase needs them badly to allow fast deployment of validated features. The fastest they are deployed the highest the chance to have paying customers, ensuring the survival of the company and increasing its chances of success.




  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • Connatix
  • BoatyardX
  • AboutYou
  • Telenav
  • .msg systems
  • Grab
  • Colors in projects