Using Branch Diagrams to Scare your CEO!
Connoisseurs find that these help when analyzing particularly complex branching strategies.
I love branching strategies, and after a long while in the biz I've become a connoisseur. The two most popular are the wicked good Mainline Model and the lackluster yet popular Cascading Model. Because branching strategies are all about modeling your software development life cycle and release process, you can have theoretical discussions about branching strategies without considering which SCM tool you're using. In practice, though, the ability to follow branching strategies depends in large part on your SCM tool and the ability of your team to use the tool.
That is in fact why many organizations follow the Cascading model as opposed to the Mainline Model. The Mainline Model can be made to work with any SCM tool in theory, but in practice it works a whole lot better if you're got an SCM tool with powerful branching and merging functionality. If you're stuck with an SCM tool that doesn't provide powerful branch and merge technology, you might be better off just sticking with the Cascading Model. (Gasp! Did I just say that?)
The problem gets particularly acute in large organizations with lots of history in their SCM systems. Following the history of a Cascading Model his harder. The history isn't obvious to someone looking at the repository. The build guy can maybe tell you, "Well, this was our trunk/mainline for a while, then we released and this branch here (pointing to a diagram scribbled on a white board) was the mainline for the next three months, and then ..." That doesn't convey information, just leaves your head spinning. Far worse, though, is that in the Cascading Model, managing the flow of change is far more difficult, because the rules for propagating changes vary from release to release, and the "from/to" paths of merge arrows on branch diagrams have be continually be rethought. Often in the Cascading Model this simply doesn't happen as it should, and it's hard for developers to easily determine whether any changes were left behind. This all leads to a higher rate of recurring bugs than the Mainline Model.
So if I say the Cascading Model is inherently flawed, why did I say it might be OK to use? Well, if you're a line engineer, the answer is because recurring mistakes aren't necessarily your problem. You probably won't get fired if you fixed bugs in the branch you were responsible for. It's someone else's problem to fix them downstream, right? Concepts like the loss of competitiveness of your software product in the market seem pretty abstract after all, and isn't that, too, someone else's job to worry about? Well, maybe you're right. If that's your situation, stick with the Cascading Model.
But, what if you care about this sort of thing!? Perhaps because something in your soul tells you that you want to be on top of your game, and totally awesome at what you do. Or because you actually are the CEO, and you are that "someone else" whose primary job it is to worry about things like the cost of recurring bugs, slower release processes, and higher defect rates, and ultimately a general lack of agility and competitive edge that go with the Cascading Model.
So, how do you use branch diagrams like the one below to scare your CEO into doing the right thing?
Let's say you're using the Cascading Model, and want to get onto the Mainlne model. Draw a branch diagram, and explain to your CEO that branch diagrams help to manage the flow of change. Mainline model branch diagrams are more consistent (and prettier, I think) than those with the Cascading Model, because they provide a consistent "pressure" to help ensure changes make it back to the long-lived central Mainline. The Mainline Model sports superior management and visualization of the flow of change. Better management of the flow of change results in higher qualty software and more agile processes.
What if your CEO is all too happy to support several old releases of your software, rather than pushing customers to move to new relases? In that case, draw the branch diagram, and point out the costs and overhead associated with each level of branching. (See Sven Erik Knop's blog post, Perforce Anti-Patterns Part 2: Overuse of branching.) Each line on the diagram generally has associated several staff resources for developing and testing, machine resources, etc.
Say you've got about the right number of branches to match your real-world requiremetns, but following the process is hard because you don't have a powerful branch and merge tool like Perforce. Draw a branch diagram on the whiteboard in the corner office, and explain how those red downward arrows on the diagrams can be really hard to do without tool support. Worse, explain that without good tool support, sometimes the work represented by those arrows doesn't occur, and then you get once-fixed bugs rearing their ugly heads again.
Or, if you're a Perforce Administrator and just want a raise, create PowerPoint diagrams rather than drawing them on a whiteboard, and talk about how you follow the arrows to make sure develop stays on track. I'd bet there's a clinical study somewhere showing that people get promoted faster when then can make good presentations! :)