The Concurrent Collective

By implementing solid practices such as coding standards, continuous integration, unit testing, pair programming, and SCM branches, you can reap the rewards of collective code ownership. When it comes to actually putting a product out to a customer that lies outside the boundary of your company (e.g. product development), I’d favor a more-contractual form of what Martin Fowler calls “Weak Code Ownership”: concurrent-collective code ownership (3CO)!

An example:

Your company makes a software package called GoodStuff. Version 2 is the current release of GoodStuff. The upcoming major release, version 3, promises to take GoodStuff to a whole new level with a swell new look and feel, a re-written reporting tool, and more. Your dilemma: (a) maintain version 2 while (b) marching forward to version 3. Solve it by running two teams optimized for each competing goal:

Team Alpha

Mantra: Keep the customer satisfied.

  • Work on the “2″ branch off the mainline.
  • Fix defects and make critical updates to version 2 of GoodStuff.
  • Release patches.
  • On release, create a branch off of “2″ (snapshot, frozen) called “2.n” where n is the top sub-branch of “2″+.1.
  • On release, merge and integrate it with the mainline branch.
  • Continue to work on the 2 branch until 3 is ready for release.
  • TEAM ALPHA IS NOT THE CRISIS MANAGEMENT TEAM. Quality practices should control both patch and major release.
  • The sprint should coincide with Bravo’s (7-30 days).
  • Alpha is more likely to work with the individual customer (customer contact reporting a bug or expressing an urgent need) than the customer team (a special purpose team put together to represent the customer perspective consisting of select customers, domain experts, internal product management, etc.).

Team Bravo

Mantra: March on the product road map.

  • You’re working on the mainline branch.
  • On release create a sub-branch (editable) from the mainline called 3.0.
  • Close the current maintenance branch (2)
  • Help your buddies in Alpha with the hand off 3.0. They have to maintain it. Why not do a deeper technical demo for Alpha during sprint review?
  • The sprint should coincide with Alpha’s (7-30 days).
  • Bravo is more likely to work with the customer team than individual customers.

Some good backgrounder on branching and concurrent development:

http://www.cmcrossroads.com/bradapp/acme/branching/
http://downloads.seapine.com/pub/papers/SCMBranchingModels.pdf

Post a Comment

*Required
*Required (Never published)