Early on in the life of a project, the development of a product progresses in consecutive releases developed in succession.
At some point in the life of the project, there may come a time where the software team finds it hard to develop multiple features requested by different customers.
At this point, some may propose branching into 2 or more product lines, one for each customer. In my experience, this is usually the worst possible decision. A team that is already struggling with one product release, now has to face the issues arising from multiple product releases.
The extra systems engineering effort is relatively small and consists of distributing features among the new branches. The testing effort is the most affected; it is directly multiplied by the number of branches. The development effort, while seemingly the same, is also significantly increased since the developers have to support change requests from multiple testing teams, then incorporate the fixes into multiple branch releases.
A multi-branch solution may make sense for a while, but the shrewd project manager should plan to merge all branches in a unifying release at the earliest possible opportunity. Creating multiple branches because a team is in arrears, however, is like trying to block cracks in a dam with your finger.
ralphgholmieh.com 