16Bit

stuff for programmers

RSS

Perhaps you have heard the phrase “Release Early, Release Often” before.  This phrase is one of the key components of Linux, and a whole slew of open source projects.  The idea is that instead of getting a fully functional version of your software, and thoroughly testing it before releasing it to your users, you make smaller incremental changes and give those to your users.  Many of you will recognize this as an important component of agile software development.

An obvious disadvantage of this approach is that early versions of any software are very buggy.  You definitely do not want to scare away your potential users by feeding them buggy software.  Once a user feels like they can’t trust you to make quality software, you’ll likely never see them again.

This is a valid concern, so everything else I say in this post must take this into consideration.  Obviously, releasing early and often is not going to be ideal in all situations, so take the time necessary to think about how a dynamic like this will affect your project.

The idea of the Release Early, Release Often methodology is that you have a small collection of changes that you focus on, and when they’re complete, you give the new version to the users, or at least, to a larger group of testers who can experiment with the program and give useful feedback about feature improvements, and bug fixes.  Essentially, this approach takes the common user, or at least your testers, and makes them developers with you.

I encourage you to consider using this kind of an approach in your work situations, as well as your own personal projects (including homework, for you students following this blog).

Initially, you have a set of requirements that you are expected to complete.  Pick a small subset of this to work on for the current cycle.  On paper, write down the set of improvements and bug fixes that you are going to work on for the cycle.  (Seriously, write it down!  And even put little check boxes by each item if you want!) Pick enough to cover a couple of days worth of work, or even just a few hours.  Go through the tasks one by one, and package up your program for release to the testing team or the general public.  If you are the testing team, spend some time at this point to step back and look at your program from new eyes, and be sure to try to break it and discover new bugs.  You can then take a look at what to do in the next cycle.  Be sure to check on newly discovered bugs, as well as other feedback from your users.

Doing this means you’ll always have a reasonably stable package to show off.  It will give you a small set of items to be working on, so it is clear what to do next.  You’re never wondering what to do next.  If you are in a team, coordinate with them.  This will ensure progress on any project, and because a broader group of people are able to see it, they can let you know if the project is going to be worth anything early on, rather than developing garbage to a final release.  Nice, shiny garbage is still garbage.

Have you ever used the Release Early, Release Often approach in your software?  What tips would you have for people who want to try it out?  Leave a comment and let us know!

View Comments

blog comments powered by Disqus