Language agnostic proactive early detection of conflicts: a prototype

Nowadays, nearly all software systems are developed by programmers working in a collaborative software development. Against this background, recent software development trends produce a version of system that unites the artifacts of simultaneous change. Usually, each developer works on their private versions of the system to secure firmness during programming. Still, this prevents them from understanding what is happening in different workspaces where their coworkers act. This can considerably impact their own work. Accordingly, conflicts occur owing to parallel work, and they become even more complicated as changes grow without being noted. Therefore, the later conflicts are identified, it is more complicated to address them, since more code has to be changed. Moreover, a conflict detected late is in most cases harder to fix because the changes that created it are no longer "recent" from a developers’ perception. Today’s approaches to solving this issue frequently force developers to amend a coworkers’ work in order to resolve a conflict – without even reaching the coworker. This way of resolving conflicts, periodically leads to inconsistent code, social conflicts, and utmost, anger and frustration inside the team. Moreover, conflict detection can be challenging for developers to do it on their own, since some code parts may have a complex structure, such as polymorphism, encapsulation, etc. The main issue of merging conflicts during collaborative development is that an important merge may lead to crucial software faults. After the industry and research got involved in the problem it was acclaimed that an early detected conflict is easier to resolve than the conflict encountered at merge or in production. Being informed about conflict as early as possible allows developers to prepare themselves, making a better judgment about how to solve it. Nonetheless, every known approach demands interaction with developer to detect conflicts, and it may lead to overbearing them with notifications – thus, making it even more problematic. Therefore, the aim of this study is to propose a solution on behalf of developers, i.e. a tool that helps in early conflict detection. With that in mind, this research turned to studying similar systems of early conflict detection in order to get a better understanding of how they work and what are their downsides. Furthermore, it combined collaborative development, version control systems and exploring future development states of software, also known as speculative analysis, in order to get an accurate account of arising conflicts and provide detailed information about them. As a result, the concept of awareness has been proposed to help developers in detecting conflicts before they occur. In terms of this study, ’awareness’ is understood as “a comprehension of all activities of others that gives a background for your action”. The approach this study takes is based on two types of awareness: awareness of change and awareness of presence. The idea is to provide accurate information about possible conflicts between members in the collaborative software development team. In other words, the main goal of dependency-based awareness tools is to decrease the number of notifications, so a developer can be focused on more applicable ones. For example, rather than creating notifications for every change in each file, there are some tools that inform developers only about simultaneous changes of files that are related to the files changed by the developer. The tool developed in this study follows all existing workspaces and changes inside them by continually checking and testing them inside the IDE. It enables earlier conflicts solving while developers still have ’fresh minds’, and allows for an easier detection of every subsequent conflict. An empirical evaluation validated that this approach actually helps in early detection of conflicts and avoids overwhelming developers with notifications as compared to existing solutions. Overall, in spite of program errors, it is mainly inexpensive and painless to spot and resolve conflicts earlier, before they reach the production and the relevant changes vanish from the developers’ minds’. At present, this knowledge is not easily accessible to developers. The approach presented in this study prepares and serves information about the possible conflicts in a continual and precise way. The aim of this information is to empower developers for better decisions about when and how to share their changes, while at the same time reducing their overload