Cassandra: Proactive Conflict Minimization through Optimized Task Scheduling
Reviewed by Fayola Peters / 2014-04-25
Keywords: Collaborative Development, Project Management
Kasi2013 Bakhtiar Khan Kasi and Anita Sarma: "Cassandra: Proactive conflict minimization through optimized task scheduling". 2013 35th International Conference on Software Engineering (ICSE), 10.1109/icse.2013.6606619.
Software conflicts arising because of conflicting changes are a regular occurrence and delay projects. The main precept of workspace awareness tools has been to identify potential conflicts early, while changes are still small and easier to resolve. However, in this approach conflicts still occur and require developer time and effort to resolve. We present a novel conflict minimization technique that proactively identifies potential conflicts, encodes them as constraints, and solves the constraint space to recommend a set of conflict-minimal development paths for the team. Here we present a study of four open source projects to characterize the distribution of conflicts and their resolution efforts. We then explain our conflict minimization technique and the design and implementation of this technique in our prototype, Cassandra. We show that Cassandra would have successfully avoided a majority of conflicts in the four open source test subjects. We demonstrate the efficiency of our approach by applying the technique to a simulated set of scenarios with higher than normal incidence of conflicts.
To help limit conflicts caused by collaborative software development, researchers Kasi and Sarma decided on a Prevention is better than cure approach. Why?
In an initial study of four open source projects from GitHub (Perl, Storm, Jenkins, and Voldemort) the authors found that merge conflicts ranged from 7.6% to 19.3%. Of the clean merges, 2.1% to 14.7% had build failures and 5.6% to 35% of correct builds incurred test failures. Also, each project had different distributions of different types of conflicts and different resolution times for each conflict type.
Two main conclusions from this work are:
- Conflicts are the norm rather than the exception. Kasi and Sarma report that this is the case no matter the size of the project (KLOC) or the number of developers involved. This provides an explanation as to why this norm exists in open projects where the majority of work is done by a small core group.
- There is no one-size-fits-all conflict mitigation technique. This conclusion is due to the large variances in the results in terms of types and number of conflicts which also varied with resolution times.
Kasi and Sarma's proactive approach resulted in task scheduling tool for conflict minimization that was effective by avoiding the majority of conflicts from their experiments. Considering that the conflict resolution times in their study spanned multiple days, ranging from an average of 6 to 23 days, Kasi and Sarma's work adds another dimension to research in the area conflicting changes parallel software development. This work addresses the premise that, less conflicts = less time spent on conflict resolution.