Dependent Changes
If you use a change tracking tool to relate changes in files to change records, you will eventually run into the dependent change problem. The situation is illustrated below.
Dependent changes
The two change requests CR1 and CR2 are related through the coordinating change PR. This creates a dependent relationship. It could be, for example, that the change in CR1 creates a new database table column that is used by the change in CR2. This means that CR1 is independent but CR2 depends on CR1. It would therefore be a mistake to merge CR2 into another branch without CR1.
Mutual Dependencies
A change is made to a file under change request CR1, then another developer makes a subsequent change to the same file under CR2. A problem is found with the changes made in CR1 so the developer revisits the file making a change under CR1 once again. The situation as it stands is illustrated below.
Mutual dependencies (simple)
The two changes (CR1 and CR2) are now mutually dependent. It would be a mistake to include CR2 without CR1 because the final correction to CR1 would be missed. Including CR1 without R2 would need a developer to ‘unpick’ the CR2 change trapped between the two CR1 changes.
More Subtle Mutual Dependencies
Mutual dependencies can be more subtle than the single file example shown above. In the illustration below the dependency is created across two apparently unrelated files.
Mutual dependencies (complex)
The first change in the top file is related to CR1, while in the lower file the CR1 change appears second. Conversely, CR2 is related to the second change in the top file but the first change in the lower file. This has created a mutual dependency across the two files. Including changes from CR1 will mean also including the CR2 change, otherwise only half the change (the CR2 change in the lower file) will be included. To maintain a consistent configuration the second change in the top file must also be included (the second half of the CR2 change). The reverse is also true.
Mitigation
As with the earlier situations these change request issues can be mitigated with a couple of precautions.
- Serialize changes — this makes mutual dependency impossible, but also extends development time by insisting that each change request is completed before the next is permitted.
- Ensure change requests do not affect common files — this also eliminates the possibility of mutual dependencies, but depends on excellent impact assessments to ensure changes avoid changing common files.
It must be noted that it is not always practicable to take these precautions, especially in commercial environments where time is a often a priority over avoiding mutual dependencies.
Summing up
That covers the more common issues you will encounter when managing parallel development. It can seem that these issues present an insurmountable obstacle that make parallel development problematic, and it would be flippant to suggest that parallel development is trivial. But it is by no means beyond any organisation to use parallel development to their advantage.
Parallel development allows projects to compress timescales dramatically by overlapping work on the same product. It also allows multiple projects to simultaneously develop new features on products in multiple overlapping release. These advantages are bought at the cost of planning ahead and managing the complexity, but this cost is almost always warranted.
Pages: 1 2
