This post is about last minute code conflicts encountered during the merge process – a problem that has for long been a hindrance to developer productivity.

We conducted a survey recently, to identify the major barriers to developer productivity, which garnered responses from 350 software development professionals, with varied levels of experience across different technologies. The respondents included developers, technical leads, project managers, program managers, IT managers, and Agile coaches, amongst others. Almost 67 per cent of the respondents reported ‘merge conflicts’ amongst the topmost challenges faced by developers. The responses also suggested that almost 42% of a developer’s time during a release is spent resolving code conflicts. That gave us enough reason to dig deeper into the topic and explore pathways to minimize the impact of merge conflicts on developer productivity.

Yes, Collaboration Too Has Cons; They’re Called Merge Conflicts

To facilitate rapid software development, engineering organizations often require multiple developers to work on different software components, features, and functionalities. And, to manage code contributions most development teams use a version control system and employ a technique called branching, which requires developers to work on code locally and then periodically integrate concurrent code changes into a master branch. In practice, developers spend hours working on codes in their respective branches, without integrating those with others’ changes. This results in code conflicts, discovered only when codes from various branches are ultimately merged into the master branch. Then, the manual conflict resolution process is unleashed.

A lot has already been done to minimize merge conflicts. Some agile development processes, such as efficient splitting of work and frequent commits, have even helped reduce conflicts to some extent. Moreover, certain version control systems claim to simplify the merge process by automatically integrating code changes. For example, extra whitespaces or changed file names can be detected easily and resolved automatically by advanced version control tools. However, there are scenarios which simply can’t be resolved without manual intervention. For example, when there are concurrent changes to the same line of code in the same file, in multiple branches, your version control system wouldn’t know which change should override others. Additionally, there are logical conflicts that aren’t detected by the version control system.

Can an Early Warning System Minimize Merge Conflicts?

Consider a business as usual scenario where John and Jane are working locally on different features of a software product in their respective branches. With her fingers crossed, Jane initiates a pull request to merge her changes to the master branch. Shortly after, John initiates a pull request to merge his changes to the master. John’s changes are incompatible with those of Jane, and the version control system flags this. Fixing the code at this stage requires huge amount of rework, as both John and Jane need to revisit their entire trail of changes. Subsequently, they also need to assess and address the impact of reversal of any code change, to ensure it doesn’t initiate a chain reaction and break other new features. Now imagine this occurring right before a committed release date. So, we see that conflict resolution is inherently complex, and the longer you work within your branch without merging your changes to the master repo the more you add to its complexity. But what if there was a system that could keep developers informed in real time about others’ work and alert them of potential direct and logical conflicts? Putting this in the context of the earlier example of John and Jane, it would imply that at any given point in time, even before committing their changes to the master, John and Jane would have complete visibility about who else is working on the same class or line of code that they are modifying. With this early visibility into potential conflicts developers can discuss their changes with teammates, make informed decisions, mitigate conflicts, and ultimately avoid a lot of rework that goes into conflict resolution right before a release is due.

Consider an alternate scenario, where John and Jane have early visibility into each other’s changes, and apparently there are no textual conflicts between their codes. But again, upon merging their codes to the master the test suite reports a failure. Possibly their codes are semantically incompatible. In this scenario, to get to the specific interaction between their codes that broke the regression tests, they will need to review each of their changes for logical conflicts. This is an even more cumbersome process, as they will need to consider the rationale behind every change. Also, a lot of time could have passed since they made those code changes, adding to the difficulty in getting those details right. In this case, only a sophisticated early warning system with the capability to speculatively assess the potential for logical conflicts, using machine learning and predictive analytics, could be of some use.

The Crux of the Matter

To sum up, given the collaborative nature of software development, conflicts seem inevitable, and can eventually lead to build and test failures. Further, conflict resolution is a huge impediment to developer productivity, and translates into delayed releases, high cycle times, and loss of business opportunity, impacting both top line and bottom line of an organization. Nonetheless, the impact of conflicts can be minimized if potential direct and logical conflicts are detected at an early stage in the development cycle. Bringing in predictability into the development process, a lot of chaos and rework can be avoided while also ensuring quality and timely releases.