Branching is evil

Almost a year ago I blogged about "Source Branches". Over the past year this somewhat have become an ongoing discussion I had repeated a few times with. In fact believe that post was my most commented one ever. Today Martin Fowler has posted about the differences between

1. Simple Feature Branch - each feature is developed on its own branch and merged when finished.
2. Continuing Integration (CI) - no branching
3. Promiscuous Integration (PI)- same as feature branching with the twist that each feature directly merges with other features that might affect it.

he also explained the risks and benefits of each approach, and I really liked that post

What I would add to that post is the human aspects that each approach brings.

Feature Branch - The easy way out

In my eyes feature branching is choosing the path of least resistance. Its an approach born in fear (I'm going to break the system before ill make it work again), taken when wanting to work in isolation without the need to constantly communicate with the rest of the team. In some cases I've seen the actual branch was born with ill intent in mind.

Promiscuous Integration - the middle ground?

The PI I think is slight better off, being the middle way it does encourage communication (to a degree), while keeping some of the apparent benefits of working in isolation. But the more I think of it the more I doubt that this can actually work (for a long period of time). Its just seems to much of a hustle. I have a strong feeling that in practice there's a good chance this will revert into a "main trunk" for bug fixes with a ongoing branch for new development (i.e. classical branching), or to a a more simple feature branching.

Continuous Integration - Encourage quality

The continuous integration path is the one I like best. The thing I like most in it, is the fact that working on a single stream of development, forces the team to sustain high quality standards. For this to work all code committed MUST not break the system. in fact when committing into a single line of development one must be sure that even if the work is half done it will no have any negative effect on the system (and in most case should be easily taken out). And quality as you all know is the only way to go fast

Disclaimer - There are business contexts in which branches CANT be avoided. and yes. modern CVS will make this a lesser issue. but to me branching is always an inferior solution to a bad situation.

Read more »

Posted in: Agile Values,Source COntrol

Source Branches

I hate branches. I think that branches are a bad solution for a stinking situation.

now before you I get jumped, I’m aware that there are cases in which branches are a perfectly legitimate solution to a given situation, but still my advice would be to try looking at what is causing the need for the branch, in my experience there is an underlying problem that the branch will not solve.

In the Last Alt .NET gathering I had a very nice discussion with Ken Egozi regarding branches. In that discussion ken and I represented the two opposites approaches. Ken on one hand is using Git and relies heavily on its great branching ability. To the point (if I understood him correctly) that he treat each source change as a different branch. I on the other hand uses SVN and try to avoid branches as much as I can.

During the last year I have used branches three times, in all of those cases I’ve came to realize that the branching was just a mechanism that allowed my to ignore the real issues but just caused us to waste time and effort. Here are the stories behind those branches:

Branching to sustain Quality

I think this is the most common use of a branch. During our development we reached a stage in which we felt that between solving defects and trying to add new features, we couldn't keep our code quality high enough. Preventing us from releasing in our desired rate (about once every 2 weeks). So we branched. Like many other project I’ve seen we thought to use he branch as our release base on which we would solve defects. leaving us to implement new features over the the main trunk.

quite simple right?

Well not really. after trying that for a while we found out that we were always merging all defect fixes from branch to trunk (as expected) AS WELL as all changes from trunk to branch!!!

when facing reality, each new feature we worked on was important enough and it was finished the business side opted to merge it into the branch so we could release it as soon as possible. The result of course was that the trunk and branch were practically identical. We just wasted time merging between the two code lines without addressing the real quality issues.

Branching To fend off a feature

Just before a trip our “customer” has insisted on implementing a couple of features in the last moment for “demonstration” purposes. Those features were quite controversial and we really didn’t want to implement them as they were especially on such a short notice (in fact we had quite an argument on how those should look). However since the “customer” was quite insisting, we choose to implement them on a branch, hoping to discard the branch at the end of the trip. We really wanted to sit down and do a proper decision on those features.

Naturally, at the end, those features were merged as is immediately after the trip, and all attempts to resist that merge failed.

Branching To avoid completing a feature

My latest experience with a branch was caused by me leaving. As part of my final days I was charged to complete a task I already started a task which is just the first step in a series of improvements which are long over due. When finishing the task, since no one actually knew how things will progress from here it was decided to put the task changes into a branch. putting it on a branch should allow picking them up later.

I myself am very much in doubt. I would say that most likely this branch will continue to exists and will never be used again. A branch in this case is just an excuse for putting this work aside still having a false sense of confidence that this can be picked up again. In fact unless those changes will be continued quite soon, they will be so much harder to pick in the future so they will never be completed.

These were my experiences with branching. In retrospect all these branches were just Mistakes on my part. In the first case instead of dealing with the causes for quality decline I tried to shove them aside into a branch. In the second instead of accepting the decision I tried using a branch to fend it off and last instead of admitting reality again a branch is used.

I would really much like to hear about you experience in using branches. Is the dislike I have towards them is just my own or do people out there share this.

Read more »

Posted in: Agile practices.,Source COntrol