Early Branching

Recently a coworker and I were looking at a versioning problem with some code that had been integrated into the current release branch (from some parallel branch) and we stopped and asked ourselves; "Why are these integ issues always so complicated, and why do we always hit them at the end of a release cycle?"

I have had the fortunate experience to work for software companies where the build was a transparent luxury that developers knew almost nothing about (It just worked!), and companies where the build was some Machiavellian Rube Goldberg machine that worked if no one made any mistakes and sage was burned at the right hour on night before a release. The interesting thing is that despite the technologies or languages or platforms that the build system used the one thing that seemed to make the biggest difference was when the branches were cut.

Of all the branching strategies I have come across the one that I've witnessed the greatest success with is early branching. Why does this seem to work better then late branching (or variants of merge/propagate early/often)? I think for a couple key reasons:

1. Branching is done for clear and coherent reasons. As soon as a release is planned a branch is cut. It ties together clear release requirements to a physical code base from which those documents can be evaluated against at any given moment.
2. It isolates potentially conflicting parallel work and helps to minimize developer collisions and build downtime
3. Reduces concurrent branch explosion. (I have seen companies with 9-10 concurrent branches all hoping they can merge them together at the 11th hour and release)
4. Potentially underestimated tasks (Hey we need to support a new platform!) are identified early and release plans (or requirements) can be adjusted accordingly.
   

While I think #1 is probably the one that gives developers and project managers the biggest benefit, #4 is where I've seen hours, days, even weeks of time saved. It is self evident that knowing potential problems early in a software cycle is better then late, but it is also surprising how often this is missed because no one foresaw any major problems. Developers are also human, and as opposed to strategies which are more laissez-faire in their version control restrictions (often relying on the wise developer to remember to do all right integing) this approach minimizes mistakes and is more forgiving when mistakes do happen. And if we have learned anything from books like Microserfs or Dreaming in Code, it's that software is hard enough without adding unforgiving process into the mix.

Gastronomique

Cooking as an art has seen a popularity explosion in America over the last 15 years. From dedicated cooking channels to reality cooking shows, from the Slow Food Movement and backlash against the fast food industry to boom in organic/fresh grocers like Whole Foods. Cooking has and continues to be an activity where I find peace. To focus on creating something exquisite and present it for others to savor is not only rewarding but meditative. I must own 50 cookbooks on various cooking subjects and recipes but it is Thomas Keller's French Laundry Cookbook that inspires the name of this blog.

Rather then the typical organized listing of recipes, Keller entitles many of his chapters "The Importance of ___". From building good relationships with specialty vendors, to big pot blanching, to the importance of staff dinner, each chapter helps the reader understand why professional cooking is a holistic approach to both people and ingredients. I find Keller's philosophies and passions apply to so much of life outside of cooking that I hope this blog will serve as my personal interpretation of this idea in software, society, and the Bay Area.

Underindulgence

I grew up in what would certainly be considered a modest to low income family in America. Both my parents were teachers in an affluent city whose primary constituents were doctors, lawyers, and retired movie stars. My family made due with what was available and if there was one lesson we learned it was sharing. Now most people think of sharing as that altruistic forfeiture in which one makes some sacrifice so that another may benefit.

20 Years later I have witnessed a variation of sharing which has become the horror of my place of work. Normally, I shrug this type of offense to the office idiot or perhaps the nameless dirty neighborhood filth-leprechaun who sneaks in to perform some vial offense that employees later come upon in the kitchen and exclaim "Holy Christ...who filled the sink with leftover curry?!"

This particular Offender has decided that whatever free office breakfast, lunch, or snack is offered they will partake of exactly 1/2 an item and leave the rest for another (sharing right?). Now the polite, if not sanitary, way to do this would be cut the item in half. Hey there is even a knife right there! Unfortunately, evidence would suggest The Offender simply uses their mighty cake-hole grinders to tear off a piece of the item leaving behind the rest for some poor soul to stumble upon and ponder "What the hell happened here?".

In the spirit of my advice to voters this last election who gave Bush the deuce run; I plead to The Offender... If you can't finish a whole muffin, consider abstaining this time around.