Branching

The team I have been working with has been reporting a surprising amount of time on merging forward branches, merging them to a RC, and dealing with merges that were not done correctly. This just supports my thesis that branching is a wasteful practices.

What I think makes sense is that a team (whole team) is given sufficiently small jobs that any one of them can be completed within an iteration. Anything the team starts it also finishes. The team also commits to the creation and use of unit tests (preferably via TDD) so that the tests they have written give them confidence that they've broken nothing with their most recent changes.

I see the team working in a common code line for all new work. This can be trunk, or a common branch. As work completes, the CI server runs all the tests (UT and AT and anything else they can automate). If all the tests run, the branch is tagged as a release candidate. When it is time to release, an existing release candidate is chosen as the next release. If there are always a number of release candidates, this should not stop the development team from working.

The branches needed are a quick-fix branch (the last production release), the current RC (being certified for production) and the common code line (current development). That's a total of three. I can concede the need for branches for experimental work: tasks that should be discarded if they don't work out. I also realize that a company may need to keep multiple production branches open for customers who have not upgraded yet. But for many companies (IT departments and SaaS producers) three branches can be enough. No matter how I've tried, I have never managed to get a production system to use less than three. I think it is close to the minimum.

This simplification pays off in reduced waste.

Speed of development does not come from the sources people often attribute. It is not a matter of typing faster, racing through work, increased pressure, rampant caffeine abuse, exceptional effort by genius programmers, cutting corners, or working longer hours (though any of those may create a temporary "bump"). I am firmly convinced that increased development velocity is a result of having higher quality work products and a simpler system to work in. This is why Lean and XP and other Agile techniques appeal to me. Having capable programmers who can enter code quickly doesn't hurt, of course. Such programmers are even more productive in a simpler system.

By delaying the point of commitment so that the customer may "cherry pick" changes for a release, complicated branching ensures a last minute "integration hell" panic at the end of every release. Last-minute integration decreases quality and complicates planning.

Mind you, in an open-source system is is still reasonable to push branch-per change management because it is acceptable that many submissions (most?) may be rejected or revised, and may take many weeks or many months to reach an acceptable state.

In commercial applications, a simple three-branch system can be a much more efficient way to get code out the door.