Wednesday, September 12, 2007

Branching for code-reuse

You wrote some code. Your app works. Now you want to do something slightly different. Timelines are tight. You want to give the new team enough control to get their job done. Yet you want to leverage what you've already done.

"Lets create a branch of the same code for the new team", you say, "Once they are through their time crunch, lets integrate the two branches."

Sounds simple. But there are three main problems with that:

  1. The time crunch never really ends. There is no time to take a break and merge.

  2. If you do find the time, you also find that the code has diverged to the point where merging becomes more expensive than maintaining multiple branches.

  3. Features are added, time goes on and re-use becomes next to impossible.


You started out thinking that re-use through branching is going to have a multiplier effect to the functionality you deliver. Initially, it is. But soon, it becomes a multiplier on how much you invest into getting simple stuff done.

So, what's the right way to do it? How do we avoid this? How do you get out of it? Well, there has been a lot written on code re-use. And I really don't feel like getting into that right now. It maybe a topic for another day. Today, I just wanted to say that if you're looking to branch your source code for re-use, then don't! If you really want to, then don't expect everything to be merged back. If you really really want to merge it back, then its going to cost you!