1.5.1 Context & definitions
The pruning requires that those product customizations deemed useful are integrated into the core-asset base by merging and refactoring [FV03]. Note, that due to the previous “grow” phase, products might have diverged to much from each other. During the pruning domain engineers need to reconcile these divergences by resolving the conflicts that arise from merging together disparate product customizations. The higher the divergences between the products, the higher the conflicts and the complexity to resolve them. When the time to resolve these conflicts exceed the time needed to perform the original changes, we are in the so-called merge problem situation [Duv07] (a.k.a integration hell or merge hell). Hence, the
merge problem arises during the pruning stage, when disparate product customizations are merged into the core-asset base resulting in a multitude of conflicts, whose time to be resolved exceed the time it took to make the original changes.
Our hypothesis is that providing application engineers integrated support for looking into other products’ code right during product development, promotes early reuse across products and small refactoring improvements, in the search lessening the conflicts of merge problem that occurs during the pruning. We refer to this practice as “code peering”. Hence,
Code peering (or peering) refers to the practice that takes place during product development, whereby product engineers inspect and compare other products’ code with their own code, and if interested, merge them together. Code peering is intended to promote early reuse of product developments across product teams, with the aim of lessening the merge problem during pruning.
The next Section delves deeper into the problem and its root-cause analysis.
1.5.2 Root-cause analysis
Figure 1.5 depicts the root-cause analysis as a mind map. The reader is encouraged to interact with the mind map at https://tinyurl.com/y9fqucpe. The nodes can be unfolded to uncover the supporting evidences for each of the claims.
Problem statement
• Merging and refactoring product customizations into the core-asset base is difficult and time-consuming.
Figure 1.5: Mind map depicting the root-cause analysis for peering into peers. Interact with it online at https://tinyurl.com/y9fqucpe.
Causes
• Large amount of conflicts. During the growth phase, products detach from the core-asset baseline, and follow their own life-cycle, without paying attention to what other product teams are developing. The more the products deviate from each other during the growth phase, the higher the chances for conflicts during the merge. These conflicts arise in cases where across product teams, the same functionality is implemented multiple times (but differently in each product) [DSB05, TMMK11]. Afterwards, domain engineers need to reconcile these different implementations into a single one that subsumes all of the others. Additionally, in cases where different functionalities are implemented across different products, conflicts also arise when these all need to be merged. What is needed is a way so that product teams do not deviate that much from each other, hence, facilitate the later merging. The difficulty of the merge conflicts, and hence, the time needed to resolve them is influenced by (1) the complexity of the conflicting lines, (2) the knowledge of the developers on the conflicting code, (3) the complexity of the files with conflict, and (4) the number of conflicting lines [MNSD17].
• Large amount of product customizations. The higher the number of products and product customizations, the higher the the chances for conflicts when these are merged together.
Consequences
• Productivity drop & higher time-to-market. The integration work and effort for porting product customizations into the core asset can become a major part in the DE teams work load, if there are many product customizations to prune, and if these cause a large amount of conflicts to resolve. This reduces the time
for DE to work on feature improvements and new feature requests [JB09]. This paces down the next core-asset baseline release, compromising product’s time- to-market.
How can we help with the problem of “merging and refactoring product customizations into the core-asset base is difficult and time-consuming”? Next Section provides the design problem along Wieringa’s template.
1.5.3 Design Problem
Our design problem formulated along the lines of Wieringa’s template [Wie14] is as follows:
Improve the merge problem
by leveraging Web Augmentation, Data Warehouse and 3-way comparison techniques for code peering
that satisfy respect focus and compatibility
so that the chances for conflicts are lessen and SPL engineers can effectively conduct the “implement” step during SPL evolution
This template reads as follows. The context to be improved would be “the merge problem” that arises during the pruning of product customizations, and the goal to achieve would be for SPL engineers to effectively conduct the “implement” step during SPL evolution, i.e. merging and refactoring product customizations. To this end, we advocate for leveraging Web augmentation (WA) [DA15], Data Warehouse (DW), and 3-way comparison&merging techniques to provide peering functionality. Web augmentation permits third parties to adapt Web sites, data warehouse techniques enable making better and faster decisions [KR02], and 3-way comparison&merging techniques help engineers compare&merge two versions of a file while also considering the origin of both files (a.k.a. common ancestor) [3waa].
In this Thesis, we utilize web augmentation techniques to enhance Github, the most popular web-based Git-based Version Control System (VCS) repository hosting service, with a peering bar that makes product teams aware of what features are other product teams currently customizing. This bar brings product engineers into a DW solution, when clicking on it. This web-based DW solution permits product teams to have an overview on how much are other product customizing the features their product is reusing. Finally, the DW solution acts as a 3-way comparison&merging enactor, that permits product teams to compare their product’s code with other products’ code, for a given feature, and merge them if wanted. This cross-product peering and reuse lessens the deviations between products, and as consequence, would lessens the conflict occurrence during the pruning phase for domain engineers. Hence, this Thesis proposes the use of both WA, DW, and 3-way comparison techniques during the grow phase, so that SPL engineers can effectively conduct “implement change” step during the prune phase.
Although, code peering encourages easy pruning, this might be an ancillary activity from an AE perspective, as for them, product development comes first. This has a main
implication: code peering should “respect the focus” of application engineers, i.e. do not interrupt product development. Additionally, support for code peering needs to satisfy compatibility requirements, i.e. the extent to which the enhancement is aligned to previous user experiences [and82]. In our case, this experience refers to the usage of Github. Hence, the solution should be compatible with Github way of working. On this grounds, we believe that WAs techniques are good means for enhancing web- based Version Control System (VCS) tools for code peering, without compromising application engineers’ focus on product development.
Next Section lists the set of research questions (RQs) addressed in this Thesis.
1.5.4 Research questions
This Thesis elaborates around three main research questions: RQ1: How is the grow phase conducted in practice?
By investigating this RQ we aim at making explicit who, when and how do stakeholders participate during the grow phase. Although the grow-and-prune model is being referred to in the literature, the nitty-gritty details have seldom been reported.
RQ2: What are the characteristics of the merge problem in SPLs? And, how can we lessen the merge problem in SPLs?
By investigating this RQ we aim at identifying the characteristics that turn the pruning phase into a merge problem, and a possible way to lessen this.
1.5.5 Contributions
This Thesis aims at contributing to the previous research questions as follows: RQ1. Description of the roles and interactions that intermingle in a grow-and-prune
approach to SPLs, motivated by the Danfoss case.
RQ2. Characterization of the merge problem and how it differs from the merge problem that also appears in traditional single-system development. We propose a new practice, code peering, as a possible way to alleviate it. This begs the question whether it is worth diverting product developers’ attention for the sake of making easier the subsequent pruning by domain engineers. Using the theory of Attention Investment [Bla02] as a narrative, we introduce four design principles that drive how code peering can be introduced for SPL development. RQ2. A realization of these principles using GitHub as the VCSs, and pure::variants
as the SPL framework. As a proof-of-concept we developed PeeringHub, a tool that supports code peering through: (1) a Chrome extension that enhances GitHub with peering bars that provide brief information about what features are other peers changing, (2) a web-based application that provides alluvial-based high-level visualizations indicating the features available for code peering, and (3) feature-based 3-way comparisons so that product engineers can analyze how a given product is changing the code of a given feature w.r.t its own.