Software Creation Mystery -

When should you Release Early and Often?

Jason Cohen posted an interesting and provocative argument against Release Early, Release Often principle followed by many agile teams.

His main points:

  • Ideas. The best ideas are not coming from users and they are bad in providing feedback (iPod). So, there is no point to release early to get their opinion and ideas.
  • Features. Minimal early set of features could be unattractive for majority of users and will turn them down for future use (Apple Newton)
  • Quality. A buggy and unpolished product could ruin your reputations
  • Architecture. An incorrect initial architecture creates waste and serious problems down the road (Netscape, Twitter)

Therefore, Jason against releasing early and often. I don’t agree.

My answer: it depends!

Evolution is the process of small frequent changes to improve and adapt to environment.

One of my posts reviewed how software team should select the best strategy: evolution, revolution or retreat. Another post compared evolution to revolution. Evolution (and aligned core Agile principles) requires early and frequent releases. Revolution pushes innovative product that should disrupt market. Requirements for a revolutionary product ideas are much higher, because it should overcome resistance, create new niche and gain acceptance of the new paradigm. Therefore, revolutionary product should be well thought and prepared to hit the mark. I should note that revolution often becomes evolution after initial release.

Decision factors for selecting strategy Release Early, Release Often (evolutionary):

  1. People. Are they highly talented and capable to come up with great ideas from the beginning ? Or should they learn and understand better the problem space, release incrementally and get more feedback from the users for initial assumptions?
  2. The Game. Is the problem (software requirements and business domain) unclear, complex, challenging and require a lot of trials and feedback? Or is the problem space well known and team already have good experience with it and can release a great product from the first attempt?
  3. The Dynamic. Is the team under a pressure to release a product early, catch at the market opportunity or help a company to survive? Or do they have luxury to take a time for designing properly and release a polished product?

There are some cases where long release cycles make sense for the company:

  1. A company has deep expertise and hired highly talented and experienced people who know how to build successful product.
  2. A company have enough funds and time to sustain long development and tolerant to inefficiency because incorrect assumptions or lack of feedback.
  3. Customers have low tolerance for risk and the software is mission- or life-critical.

However, I expect that for many software teams the most optimal strategy will be evolutionary – Release Early, Release Often.

I partially agree with Jason that most users will not help with ideas or provide meaningful feedback. Also it is a bad idea to ship buggy, unfinished and useless product. But a team could get more than user feedback from early and frequent releases:

  • release! This is a huge and most important criteria of development success – the product is releasable and working
  • integrate and put the product pieces together, which is almost impossible to replicate in the test environment
  • practically experience work of the live product – infrastructure and production problems, performance, scalability and user interactions in their environment. These problems can radically change the view on architecture
  • reality check – learn from how people use the product: validate initial assumptions, collect praises and complains, real usage patterns, statistics and maybe even some ideas from users 🙂
  • emergence of the new ideas and process improvement after experiencing product in the wild live environment

A software company should avoid treating users as guinea pigs for their early experiments, but nothing can beat practical benefits of releasing code and learning from it.

“In theory there is no difference between theory and practice. In practice there is.” — Yogi Berra

Referenced post: Releasing Early Is Not Always Good? Heresy! by Jason Cohen

AddThis Social Bookmark Button AddThis Feed Button


This blog have little value without you and your comments, thoughts and discussions. Please, leave your comments. You are welcome to debate and criticize any idea, but, please, don't attack other people. Thanks for your contribution!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Subscribe without commenting

Software Creation Mystery -
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 License .