Skip to content

Commit

Permalink
Abstract
Browse files Browse the repository at this point in the history
  • Loading branch information
swissmanu committed Aug 21, 2020
1 parent 6c9ba26 commit 63d98a9
Show file tree
Hide file tree
Showing 2 changed files with 4 additions and 4 deletions.
2 changes: 1 addition & 1 deletion abstract.tex
Original file line number Diff line number Diff line change
@@ -1 +1 @@
ABSTRACT WILL BE REWRITTEN An application implemented using RxJS is unintuitive and time-consuming to debug. We will explore the practices software engineers apply during debugging and take a close look at the challenges they face in this workshop paper. On the way to propose solution concepts, we will validate previously identified struggles in an observational study and elaborate on previous research efforts in the field of reactive debugging.
RxJS is a popular library to implement data-flow-oriented applications with JavaScript using reactive programming principles. The library's domain specific language allows the sophisticated description of data-flow compositions. Though this way of programming bears new challenges for traditional debuggers: Their focus on imperative programming limits their applicability to problems originated in the declarative programming paradigm. The goals of this paper are: (i) to understand how software engineers debug RxJS-based applications, what tools do they use, what techniques they apply; (ii) to understand what are the most prevalent challenges they face while doing so; and (iii) to provide a course of action to resolve these challenges in a future iteration on this topic. We learned about the debugging habits of ten professionals using interviews, and hands-on war story reports. Based on this data, we designed and executed an observational study with four subjects to verify that engineers manually augment source code with trace logs instead of using specialized debugging utilities. In the end, we identified the lack of fully integrated RxJS-specific debugging solutions in existing development environments as the most significant reason why engineers do not make use of such tools. We decided to elaborate on how to resolve this situation in detail as the topic for our future work.
6 changes: 3 additions & 3 deletions paper.tex
Original file line number Diff line number Diff line change
Expand Up @@ -65,7 +65,7 @@ \section{Introduction}

According to the IEEE Standard Glossary of Software Engineering, \emph{debugging} is an activity ``to detect, locate, and correct faults in a computer program.''\cite{ieeeglossary} From interpreting memory dumps, manually adding log statements to trace program execution up to the point where specialized debugging programs can interrupt a running process and interact with it on a low level, debugging utilities took different forms over time.

Modern IDEs and internet browsers ship with their own set of debugging tools. These traditional debuggers are specialized in working with imperative, control-flow oriented program code. E.g., when an engineer wants to know which part of the program called a particular function, the call stack gives a clear answer to this question. Assuming a data-flow oriented program implemented using RP, the question, what transformation function processed a piece of information right before another cannot be answered using a call stack anymore: The stack leads to the internals of the RP runtime environment rather than to the transformations logical predecessor.
Modern IDEs and internet browsers ship with their own set of debugging tools. These traditional debuggers are specialized in working with imperative, control-flow-oriented program code. E.g., when an engineer wants to know which part of the program called a particular function, the call stack gives a clear answer to this question. Assuming a data-flow-oriented program implemented using RP, the question, what transformation function processed a piece of information right before another cannot be answered using a call stack anymore: The stack leads to the internals of the RP runtime environment rather than to the transformations logical predecessor.

These exemplary questions demonstrate the limits of a traditional control-flow oriented debugger, which is not able to interpret RP abstractions, and as a result, cannot give the correct answer to a data-flow-specific inquiry. Regardless of previous research efforts \cite{10.1145/2577080.2577083} \cite{10.1145/2884781.2884815} \cite{10.1145/3180155.3180156} in the field of RP debugging, we will show in this paper that engineers struggle nonetheless in applying effective techniques and utilities. For doing so, we interviewed several software engineers and collected ``war stories'' about the challenges they face in their day-to-day jobs when applying RP. Based on this collected evidence, we will validate their statements in an observational study using RxJS and search for an answer to our first research question:

Expand Down Expand Up @@ -208,7 +208,7 @@ \subsubsection{RxViz}
\section{Interviews and War Stories}
\label{sec:interviews}

On the way of finding our interview partners and war stories reporters, we noticed it to be a challenge on its own to find people who understand themselves as users of RP and related technologies. E.g., even though Angular makes heavy use of RxJS, we will see that many engineers do not directly interact with its abstractions when building ``basic'' UIs. In the end, we were able to conduct interviews with 10 engineers and collect war stories from another five.
On the way of finding our interview partners and war stories reporters, we noticed it to be a challenge on its own to find people who understand themselves as users of RP and related technologies. E.g., even though Angular makes heavy use of RxJS, we will see that many engineers do not directly interact with its abstractions when building ``basic'' UIs. In the end, we were able to conduct interviews with ten engineers and collect war stories from another five.

\subsection{Interviews}

Expand Down Expand Up @@ -403,7 +403,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 10 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 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 theme for our own future work on the topic.

Expand Down

0 comments on commit 63d98a9

Please sign in to comment.