George Mauer is on the Net

Screencast: Keeping Features Out Your Way With Branching

Pop quiz:  What’s the software developer’s biggest enemy?  It’s not marketing.  It’s not those snot-nosed DBAs.  The rigid chair that will invariably give you arthritis?  Nah.  Your know-nothing boss?  Not even close.  No, the developer’s biggest enemy is the customer.

That’s right customers and their god d*mn feature requests and bug reports!  Life would be so much easier without them.  And acknowledging the absurdity of that statement, unless you are some kind of programmer Adonis (which unlike a regular Adonis physically implies only that your esophagus is invulnerable to lesions caused by Bawls) and write flawless code you will have to deal with feature requests that can rapidly pile up and overwhelm your development process.

I had mentioned previously on this blog that I am working with a team of Indian contractors and this is exactly what they found happening with the latest high stakes omg-fix-this-now-or-we-all-die release.  The team was behind and the release went out mere minutes before users started working with it.  Of course in the rush to finish on time bugs cropped up and features were left out.  Lots of features.

So immediately the next morning, with tickets raining down and demands for new drops every day the team got to work.  And the daily releases never came.  On the 3rd day we finally dived into their process with them to identify the problem.  

Simply speaking, they couldn’t reach a stopping point.  By the time certain features were ready to go others were half-implemented and so no release could be scheduled.  It was like some sort of real life Zeno’s paradox.  Fortunately this one has a solution.  Fully acknowledging that it is probably named differently in a dozen books and Agile pamphlets (just not any that I’ve seen), I call it branch-per-release or “how to use source control to get yourself out of a tight spot”. 

The idea is blatantly simple:

  1. Chose a release date
  2. Decide which features will fit in that release date
  3. Use your source control chops to create a branch for that release
  4. Decide what release each of the features on your plate goes in
  5. Create a branch for each of those releases
  6. Implement each feature set in the branch for its release
  7. When development on a branch is completed and tested, reintegrate into trunk.
  8. Rinse, repeate.

I have created a presentation and a series of screencasts (3 x 5 minutes thank you Jing) to demonstrate the process.  And here they all are:

Apparently embedding videos on is a pain in the *ss (as is code highlighting) so as mere links they must stay.

Creative Commons License
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.


June 4, 2009 Posted by | ALT.Net, Programming | Leave a comment