At Taodyne, we pass all these, yet our project took a major blow because there is at least one other key rule that goes above all these. I will call it rule zero, and it impacts how you write code.

Do you go in a single direction?

The code-oriented formulation of rule zero is the following:

Do you avoid branches like the plague?

Do not ever fork your codebase

With tools like Git, Mercurial or Bazaar, branches are much easier to manage than they were in the past. They actually became part of the process. With these distributed source control systems, you keep creating and merging branches for practically everything you do.

So why the title, “Branches are evil” (a favorite of über-geek Dennis Handly)? Here, by “branch” I don’t mean the kind of minor branching where two variants of the codebase differ by a few lines of code. This has to happen as you develop code. The problem is when the fork affects the design itself, or the direction the project is following.

My biggest mistake at Taodyne was ignoring this key rule. It all started with a simply thought experiment about an alternative design, quickly followed by a little bit of experimental code. And I forked our code. But then, others started building useful stuff on top of that branch.

When we decided to drop that alternate design, we had a big problem on our hands. We needed to salvage all the good stuff on that branch, that had been written against a completely different design. We have spent several months trying to reconcile these two conflicting designs that had conflicting objectives. As a result, I spent countless hours trying to fix bugs that were a result of merging code with different assumptions.

When a single mistake delays the release of your product by a few months, you know you did something solidly wrong. I thought I’d share the experience so you won’t do the same mistake.

From what I understand, you tried some design and it took a long time before you take the decision it was not going to the right direction. I think the biggest mistake is to have built additional layers on something that was still under evaluation.

Suppose you were not using branches but was willing to test a new design, you would have made modifications on the main and only branch and come a few months later to the same conclusions. Reverting to the old design while keeping some enhancements based on the new design would have been painful also.

As a good rule, I think that experiments should be kept short in scope and time. And A set of success criteria (performance, ease of use, extensibility, …) should be defined at start. Based of the results, you can then decide to persevere or pivot a la Lean startup ;-)

Sébastien

PS: btw was willing to log in with twitter OAuth but stopped because WordPress asks for rights to change my profile and send tweets on behalf of me ??!!

It would be nice if all our experimental branches were orthogonal or short lived and quickly folded back in or not, but many theories are not orthogonal and their implications can be so vast that we cannot easily evaluate them. i.e. we must extensively build on top of them in order to evaluate them. Indeed, I think a “startup” is inherently based on such a theory.

However, software is in a special class because the risk of building on top of a theory can be significantly reduced by automatic translation to other forms. For example, Christophe’s back-porting conversions are largely deterministic and could (in theory) be automated, but because it is done manually, it is time consuming and bugs are introduced. Of course, presently, building such automation is often difficult and time consuming, too.

It is good to go in a single direction, and for that direction to accurately predict future value, but beyond that, it is my goal to make pivots as easy as possible through automation.