Better Integrate Main References

Author: swissmanu

paper.tex

@@ -283,9 +283,9 @@ \subsection{Insights}
 \section{Validation}
 \label{sec:study}
 
-Almost all participants from our interviews and war story reports showed a tendency to manually modify source code with trace logs during the hypothesis instrumentation phase when debugging RxJS code. This practice is often not perceived as efficient since the evaluation and interpretation of trace information tends to be cumbersome and very time-consuming. Also, removing log statements after a successful debugging process might leave new bugs in production code if not done carefully. We identified this technique as one of the primary debugging practices when software engineers work with RxJS-based code.
+Almost all participants from our interviews and war story reports showed a tendency to manually modify source code with trace logs during the hypothesis instrumentation phase when debugging RxJS code. This practice is often not perceived as efficient since the evaluation and interpretation of trace information tends to be cumbersome and very time-consuming. Also, removing log statements after a successful debugging process might leave new bugs in production code if not done carefully. We identified this technique as one of the primary debugging practices when software engineers work with RxJS-based code, which supports earlier results by Banken et al. \cite{10.1145/3180155.3180156} further.
 
-That is why we saw demand in validating this statement about manual code modification for debugging reasons with an observational study. Our study sought to validate the following hypothesis:
+That is why we saw demand in validating this statement and previous findings about manual code modification for debugging reasons with an observational study. Our study sought to validate the following hypothesis:
 
 \begin{itemize}
 	\item \emph{Hypothesis: If software engineers must solve an RxJS-based problem, then they will instrument the code manually in order to understand its behavior.}
@@ -358,17 +358,17 @@ \subsection{Study Execution and Results}
 
 \subsection{Interpretation}
 
-We were able to observe how all subjects predominantly used manual source code augmentation by adding trace logs. Two of them used traditional debugging utilities in order to inspect the program's state at runtime. All subjects used the new information gained to refine their hypothesis about underlying problems before they started a new iteration in the debugging process. We could not observe the extraction to and reintegration from an external tool. All subjects exhibited the debugging behavior described in our hypothesis.
+We were able to observe how all subjects predominantly used manual source code augmentation by adding trace logs, which confirmed previous results by Banken et al. \cite{10.1145/3180155.3180156}. Two of the subjects used traditional debugging utilities in order to inspect the program's state at runtime in addition. All subjects used the new information gained to refine their hypothesis about underlying problems before they started a new iteration in the debugging process. We could not observe the extraction to and reintegration from an external tool. All subjects exhibited the debugging behavior described in our hypothesis.
 
-Even though two subjects stated in the after-action survey to regularly use rxjs-spy for debugging RxJS programs, neither S1 nor S3 made use of this library during the experiment part of the study.
+Even though S1 and S3 stated in the after-action survey to regularly use rxjs-spy for debugging RxJS programs, neither of them made use of this library during the experiment part of the study.
 
 Interviewing professionals, consolidating RxJS hands-on experiences from the war stories, and evaluating the results from our observational study showed us that software engineers use a variety of practices, tools and utilities to debug RP programs. Beside the habit of adding trace logs manually, we saw them evidently trying to answer their debugging hypotheses using traditional, imperative-focused debugger utilities. The later way of debugging was repeatedly commented as unsatisfying as these utilities cannot handle RP constructs, and with this, cannot help to detect problems located within these at all. The former way, the introduction of manual log statements, was both described as the prevalent way of debugging RxJS or as ``the last resort'' when no other debugging technique helped before.
 
 We heard further how engineers isolate specific observables from bigger data-flows and how they inspect those in sandboxed environments and visualizers. This helps them understanding the observable life cycle and value emitting behaviors better and iterate faster in order to resolve problems.
 
 More than 50\% of our 14 peers throughout the interviews, war story reports and the experiments after-action survey stated to know about specific RxJS RP debugging tools. It was apparent that all subjects during the observational study refrained from using any of them, though. It is our speculation that the subjects knowing about specific tools held themselves back from using them because they perceived the effort of setting them up (e.g., installing and configuring rxjs-spy) as too time-consuming. Not having the ``right'' tool available without significant additional effort is also what we interpret from the statement by S4: Though they would have started to extract parts of the data-flow and inspect it with other tools, they would have done so only after the 25 minutes of the block expired; Hence a more accessible way allowing such analyses would have influenced the behavior of the subject.
 
-The best RP debugging tools are useless if either the hurdle to use them is too high, or engineers do not understand in which particular part of the debugging process they can benefit from them. Hence, we are able to postulate an answer to our first research question RQ1: The most significant challenge software engineers face when debugging RxJS-based programs is to know \emph{when} they should apply \emph{what} tool to resolve their current problem in the \emph{most efficient} way.
+The best RP debugging tools are useless if either the hurdle to use them is too high, or engineers do not understand which particular part of the debugging process they can benefit from them. Salvaneschi et al. \cite{10.1145/2884781.2884815} provided in their previous study on \emph{Reactive Inspector} for \emph{REScala} evidence on the effectiveness of a fully integrated RP debugging solution, which supports developers in their daily work using the Eclipse IDE. Hence, we can postulate an answer to our first research question RQ1: The most significant challenge software engineers face when debugging RxJS-based programs is to know \emph{when} they should apply \emph{what} tool to resolve their current problem in the \emph{most efficient} way.
 
 \section{Future Work}
 \label{sec:future}