Where does the origin of the Release Early, Release Often (RERO) principle come from?
-1
-
1This seems like a valid question. I don't understand why it's gotten so much negative attention. – wogsland Mar 9 '17 at 1:27
4
One of the earliest references to this term originate in Jim McCarthy's book Dynamics of Software Development. This term seems to also be embedded in the Lean Startup movement, which built upon ideas in Lean Manufacturing, TRIZ, and other sources explaining how to evaluate an experimental product and check if it fits the market before investing too much effort in its completion.
3
Eric S. Raymond is credited with popularizing "Release Early, Release Often" in his essay "The Cathedral and the Bazaar" where he credits Linus Torvalds as using that approach in the development of Linux to it's success.
0
As an addition to the other answers, the following statements were found:
What makes this possible in software is that most software failures do not have life-threatening consequences.4 As a result, it is usually faster and cheaper to learn from failure than to attempt to anticipate and accommodate it via detailed planning (which is why the RERO principle is often restated in terms of failure as fail fast).
Let new engineers release
So crucial is the RERO mindset today that many companies, such as Facebook and Etsy, insist on new hires contributing and deploying a minor change to mission-critical systems on their very first day. Companies that rely on waterfall processes by contrast, often put new engineers through years of rotating assignments before trusting them with significant autonomy.
Analogies
To appreciate just how counterintuitive the RERO principle is, and why it makes traditional engineers nervous, imagine a car manufacturer rushing to put every prototype into “experimental” mass production, with the intention of discovering issues through live car crashes. Or supervisors in a manufacturing plant randomly unplugging or even breaking machinery during peak demand periods. Even lean management models in manufacturing do not go this far. Due to their roots in scarcity, lean models at best mitigate the problems caused by waterfall thinking. Truly agile models on the other hand, do more: they catalyze abundance.
