Many times when managers first consider parallel development, it appears to be a very effective way to manage changes to concurrent streams of development. This is somewhat true if the project uses an SCM technology that allows for stable branching and establishes discreet project and maintenance branches in which developers can modify their code.
However, what is often forgotten is that while branching is a great way to separate code changes, at some point merging will have to occur. In other words, parallel development is meaningless without a branching and merging model to support the development. This brief article hopes to provide guidance for approaching and performing parallel development.
Why Parallel Development
Some claim that parallel development will increase productivity by allowing two or more streams of development to occur at the same time. This is a tempting scenario for Product and Project managers who are always looking for ways to improve their time-to-market goals. Moreover, parallel development may occur within a project or across projects (and often times both).
In many cases, parallel development occurs within a project release context where two or more developers are working on the same piece of code at the same time in different workspaces. In other cases, parallel development occurs across streams of development including the: current project release (2.0), future release (2.1), maintenance or bugfix of past releases (1.0.1), and customer specials or variants (2.0a, 2.0b, etc).
Given the above possibilities for parallel development, most groups end up performing parallel development at one of these levels (within a project or across projects). And finally it is important to understand that parallel development may occur anyway so it is important to learn the concepts of parallel development and what can be done to approach it in a constructive and productive way.