Remove Percentages

Author: swissmanu

paper.tex

@@ -89,7 +89,7 @@ \section{Introduction}
 
 \subsection{Reactive Programming}
 
-RP is a declarative programming paradigm that has its origins in FP. While engineers use imperative programming languages to specify every step \emph{how} a program has to do something, declarative languages allow to describe \emph{what} the program should achieve ultimately. A runtime system then figures out a way to satisfy that description and executes it. RP functionality is usually provided in form of a language extension for a specific programming language (e.g. REScala for Scala\cite{10.1145/2577080.2577083}) or as a library (e.g. RxJS for JavaScript\cite{rxjs})
+RP is a declarative programming paradigm that is strongly influenced by FP. While engineers use imperative programming languages to specify every step \emph{how} a program has to do something, declarative languages allow to describe \emph{what} the program should achieve ultimately. A runtime system then figures out a way to satisfy that description and executes it. RP functionality is usually provided in form of a language extension for a specific programming language (e.g. REScala for Scala\cite{10.1145/2577080.2577083}) or as a library (e.g. RxJS for JavaScript\cite{rxjs})
 
 Either way, both usually provide a (i) domain specific language (\emph{DSL}) to describe data-flow graphs, how they depend on each other and how data flowing through should be transformed. At program execution, a (ii) runtime environment evaluates these descriptions and creates a representation of the specified graphs. It then takes care that values are processed and propagated correctly through them as well as that a consistent system state\cite{10.1145/2501654.2501666} is always maintained.
 
@@ -339,7 +339,7 @@ \subsection{Study Execution and Results}
 	\label{tab:subject-results}
 \end{table}
 
-The survey responses available in Table~\ref{tab:subject-survey} showed that 75\% (S2, S3 and S4) of the subject population had two or more years of experience with RxJS. Where all of them use RxJS to develop frontend applications, S4 declared having used  RxJS for backend development as well. When asked what tools they usually use for debugging, S2, S3 and S4 stated to use the traditional debugger of their IDE. S1 and S3 leverage additional tracing functionality of rxjs-spy, and all four of our subjects use manual log statements.
+The survey responses available in Table~\ref{tab:subject-survey} showed that S2, S3 and S4 had two or more years of experience with RxJS. Where all of them use RxJS to develop frontend applications, S4 declared having used  RxJS for backend development as well. When asked what tools they usually use for debugging, S2, S3 and S4 stated to use the traditional debugger of their IDE. S1 and S3 leverage additional tracing functionality of rxjs-spy, and all four of our subjects use manual log statements.
 
 \begin{table}
 	\caption{After-action survey responses per subject.}
@@ -358,15 +358,15 @@ \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. Only 50\% 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. 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.
 
 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.
 
 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 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.
+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.
 
@@ -375,7 +375,7 @@ \section{Future Work}
 
 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.
 
-The observation that 50\% 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.
+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.
 
 This leads us to the answer to our second research question RQ2: We want to improve the experience of debugging RxJS-based applications by providing RP specific debugging utilities where software engineers expect them the most: Fully integrated with the traditional debugger they know from their IDE or browser developer tools.
 
@@ -409,7 +409,7 @@ \subsection{Construct Validity}
 \section{Conclusion}
 \label{sec:conclusion}
 
-In this paper, we have explored how software engineers debug data-flow-oriented programs implemented using RxJS. We presented an observational study to validate a hypothesis based on the outcome of ten individual interviews and hands-on experience reports from software engineering professionals. More than 50\% of the engineers we worked with during our research told us that they know of the existence of specific debugging tools for RP with RxJS. Nonetheless, the experiment conducted with four participants allowed us to prove that engineers augment source code manually with trace logs instead of using such specialized utilities.
+In this paper, we have explored how software engineers debug data-flow-oriented programs implemented using RxJS. We presented an observational study to validate a hypothesis based on the outcome of ten individual interviews and hands-on experience reports from software engineering professionals. More than 50\% of the 14 engineers we worked with during our research told us that they know of the existence of specific debugging tools for RP with RxJS. Nonetheless, the experiment conducted with four participants allowed us to prove that engineers augment source code manually with trace logs instead of using such specialized utilities.
 
 We identified the fact that RxJS specific debugging tools are not tightly integrated with existing, traditional debuggers in IDEs and the developer tools of internet browsers as the main reason why software engineers do not use them more often. In order to lower the effort necessary to use specialized RP debugging tools for engineers, we declared the integration of such as the matter for our own future research.