Release early, release often

by | 21.10.2020 | Product Management

I guess we’ve all heard this. Here’s a little background to why this might be a real good approach for you – or why not.

Linux

The Linux Kernel is developed in a bazaar-style approach. Historically, software has been built in a more cathedral-style approach as in “huge increments, huge cycles”.

The bazaar-style approach is arguably what made Linux so successful as a software development project. It introduced kind of a swarm-intelligence to stakeholdership, fueled by the real-time connectivity the internet provides.

Cathedral-style Development

  • long release cycles
  • bugs are fixed in between huge releases
  • slow traction

In the cathedral-builder view of programming, bugs and development problems are tricky, insidious, deep phenomena. It takes months of scrutiny by a dedicated few to develop confidence that you’ve winkled them all out. Thus the long release intervals, and the inevitable disappointment when long-awaited releases are not perfect.

Bazaar-style Development

  • Release early, release often
  • short release cycles
  • short feedback loops between developers and users

In the bazaar view, on the other hand, you assume that bugs are generally shallow phenomena—or, at least, that they turn shallow pretty quickly when exposed to a thousand eager co-developers pounding on every single new release. Accordingly you release often in order to get more corrections, and as a beneficial side effect you have less to lose if an occasional botch gets out the door.

Takeaways

  • the Linux Kernel is developed with a bazaar-style approach, leveraging a huge amount of developers connected through the internet
  • Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone (“Linus Law”)
  • Keep Developers happy through high velocity and quick turnarounds
  • make effects of work visible to a broader audience immediately to satisfy people’s egos
  • the one who finds a problem is not necessarily the one who understands or even fixes it; thus, the more skill you can throw at problems, the quicker they get identified and solved

Read a more in-depth view on this in this great article on catb.org

CommunityNew

The DevOps Awareness Program

Subscribe to the newsletter

Join 100+ cloud native ethusiasts

#wearep3r

Join the community Slack

Discuss all things Kubernetes, DevOps and Cloud Native

Related articles6

No Results Found

The page you requested could not be found. Try refining your search, or use the navigation above to locate the post.