You may have heard of the Joel Test to evaluate startups:

  1. Do you use source control?
  2. Can you make a build in one step?
  3. Do you make daily builds?
  4. Do you have a bug database?
  5. Do you fix bugs before writing new code?
  6. Do you have an up-to-date schedule?
  7. Do you have a spec?
  8. Do programmers have quiet working conditions?
  9. Do you use the best tools money can buy?
  10. Do you have testers?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing?

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.

  1. Do you go in a single direction?

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

  1. 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.


2 thoughts on “Branches are evil

  1. Hello Christophe,

    Although I acknowledge the bad consequences of the scenario you tell us, I would not jump so quickly on the same conclusion : “don’t use/avoid branches”.

    Branches are useful and used mainly by many programming teams to:
    – Manage versions (stable, unstable, shipped, …)
    – make experiments and gain (quick) feedback/knowledge

    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 😉


    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 ??!!

  2. 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.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s