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.

START

RandsInRepose writes the best article I've seen in a long time. I am also daunted by large tasks, and especially large learning tasks. Even large drudgery tasks can give me pause from time to time. His answer is so simple, and so reasonable.

Start.
Iterate.
Mix it up.

I noticed in the tree story that he had one more bit of advice -- get some help.

Nice points to ponder.

Branching as a Coping Mechanism

Branching is a coping mechanism.

There is a lot of branching and release-time cherry-picking of features in the commercial software world. It seems to alleviate some pain and make the process more manageable, but I fear this is at too great a cost. Many development groups branch due to dysfunction.

Note that I am not talking about open source projects. I'm specifically speaking about commercial projects where programming talent is not free. I'm also not talking down distributed version control, where every checkout is really a separate branch. I am concerned more about use of branches for the wrong reasons and at a high cost.

Often branching is used to put off integration. This is a losing game. After so many changes to the trunk a branch will no longer slide seamlessly into the release stream. We can work around that problem (itself a work-around) if we merge forward all branches periodically so that they track the trunk more closely. This activity is time spent on features that may not be released this week or even next. Or maybe ever.

Branching can seem like a handy way to create flexibility for product team, as they can de-/re-prioritize as they please up until the last minute . This would follow the lean principle of deferring decisions to the latest responsible minute, if it were not for the word "responsible". They've already spent the money to have the features implemented by the time they decide not to release the feature. Wouldn't it have been more responsible to only spend developer time and effort on things they definitely need to deliver?

In several businesses, the branches are a vote of no-confidence in the development team. If a team regularly accepts more work than it can complete, it makes sense to keep the work separated until it really completes.This is clearly a failing both in planning and execution. Better to only assign work that is completable in a reasonable time, and to build with techniques like TDD that give a better sense of real completion.

In some cases, branching is required because the QA team is so backlogged that it may be weeks or months before they will have the opportunity to test the work that has been done. In this case, the answer is probably not to make an even larger backlog for the QA team. Unfinished work is waste. There is little reason for piling waste up on top of waste.

The underlying problem is that branches are a perishable inventory. More is not better. Each incomplete branch has to be maintained or eliminated. Tossing out the work is obvious waste. Continuing to maintain branches you're not releasing is also waste. Letting the code rot until it no longer can merge to the trunk is also waste.

If a team takes on small, immediately-releasable units of work, and completes them quickly then branching becomes unnecessary. If the work they do is the most important work they can do, then the flexibility for *not* release that work is unwelcome. If the team practices CI so that it always has something ready to release, then it is hard to find reasons to branch. If your agile team became truly agile, you could obviate most branching and free up a lot of manpower for other important tasks.

But imagine that you had to ask developers to make a new branch for their work and had to explain that it was because you didn't bother to break their task into reasonably-sized slices, because you want to de-prioritize it, that they would have to maintain the branches until someone gets around to testing, and that you don't really expect to be able to release it.

There are good reasons for branching, such as when making experimental changes you may very well want to discard. Alternatively if you examine your reasons for branching, you may not like what you learn.

If you find yourself in a dysfunctional branching hell, the answer is not to stop branching. The answer is to obviate branching by producing less, producing it better (with more and better testing), and integrating it sooner. Eliminate the need, then the practice.

Transformation by Obviating Coping Mechanisms

When faced with ugly code I learned a simple pattern. First I would break the code into paragraphs and comment it liberally. Since I hate code that requires comments, my next step is to take one comment at a time and change the code to make the comment unnecessary. Often that is the matter of changing a variable name or function name. Sometime it takes extracting a function or method. Sometimes it means introducing explanatory variables. Eventually the code doesn't need any of the comments anymore. It is smaller and cleaner and usually faster as well.

Then I started working with teams. I found that teams accrue process and practices the way that code acquires comments. They are in a difficult situation, and so they add more steps, more process, more tools, more tricks. Ultimately ripping away the existing process will leave the team with the original problems and no coping mechanisms, just as deleting comments would have left the code just as crufty and perhaps more unreadable than before.

The secret with the code wasn't to rip away the coping mechanisms, but to obviate them and then remove the redundant comments.

Now I'm seeking out coping mechanisms, looking for ways to fairly judge them, reach beyond the coping mechanisms and obviate them, and replace them with something more functional. It's a simple pattern but surprisingly hard to apply at times.

Move from ObjectMentor

On Aug 4, 2008 I moved from Object Mentor where I was an Agile coach and mentor to various companies to Textura where I have been an internal coach and now am managing a team of developers. I realized that I need a new professional outlet now since I won't be filling up the pages of the Object Mentor blog.

My friends recommended that I start working on personal branding by starting up an individual pro blog outside of my work environment. I will be writing from myself, and not from the point of view of any employer. Welcome to the result of that.

Now I am working the agile transition from a whole different angle. Hopefully, this will be a great time of growth for me as well and I intend to blog my observations about agile practice as usual. I hope it will be a place where people can participate by giving me new observations, advice, and even possibly an occasional boot to the head.

Enjoy. We will cover many miles together.