Editing

Author: swissmanu

paper.tex

@@ -283,7 +283,7 @@ \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, which supports earlier results by Banken et al. \cite{10.1145/3180155.3180156} further.
+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. Like Banken et al. \cite{10.1145/3180155.3180156} before, we identified this technique as one of the primary debugging practices when software engineers work with RxJS-based code.
 
 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:
 
@@ -358,7 +358,7 @@ \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, 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.
+We were able to observe how all subjects predominantly used manual source code augmentation by adding trace logs. 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 starting 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. Further, we could verify previous results by Banken et al. \cite{10.1145/3180155.3180156} successfully as well.
 
 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.
 
@@ -368,12 +368,12 @@ \subsection{Interpretation}
 
 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 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.
+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 the \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}
 
-We see the biggest shortcoming of current RxJS-oriented debugging solutions like rxjs-spy, RxFiddle, or RxViz in fact that they are not integrated in established development environments (e.g., IDEs or internet browser developer tools). This leads to the practice of manually augmenting code itself rather then working with it in a less obtrusive, fully integrated way as we were able to proof in our observational study. Using specialized utilities is an extra effort an engineer has to invest every time they want to debug a data-flow: Either tagging an observable for rxjs-spy or extracting parts of it to an external environment, all of these practices require engineers to ``go the extra mile'' in order to inspect the runtime behavior of an RxJS-based application. The additional effort might be neglectable when treating a rather complex data-flow composition, but it holds back engineers from applying the tools to simple observables like in the first block of the experiment we conducted.
+We see the biggest shortcoming of current RxJS-oriented debugging solutions like rxjs-spy, RxFiddle, or RxViz in fact that they are not integrated in established development environments (e.g., IDEs or internet browser developer tools). This leads to the practice of manually augmenting code itself rather then working with it in a less obtrusive, fully integrated way as we were able to proof in our observational study. Using specialized utilities is an extra effort an engineer has to invest every time they want to debug a data-flow: Either tagging an observable for rxjs-spy or extracting parts of it to an external environment, all of these practices require engineers to ``go the extra mile'' in order to inspect the runtime behavior of an RxJS-based application. The additional effort might be neglectable when treating a rather complex data-flow composition. However, it holds back engineers from applying the tools to simple observables like in the first block of the experiment we conducted.
 
 The observation that two out of four of our study subjects tried to debug an RP application with traditional, imperative-centric debugger utilities, as well as related statements from the interviews and war stories, strengthened our assumption regarding tool integration. Engineers expect the debugging tools they know and rely on to give correct insight on every program, no matter the paradigm (imperative or declarative) with which it got implemented.