*5.4.2 Enrichment strategy*

To make prey (bugs) more visible as well as to understand the patch, the participants used various enrichment strategies. They realigned/regrouped the modules so that the connections between them were more visible. For exploring the cues, they kept two patches side-by-side. For example, participants placed the editor and documentation side-by-side for better view of each window. This suggests that IDEs should allow multi-context views allowing end user programmers to view different dimensions of code and allow easy manipulation of the environment.

### *5.4.3 Navigational strategy*

The participants carved out regions based on the data flow structure of Yahoo! Pipes and foraged for cues down each path separately. Whenever they found a weak scent (perceived value), they backtracked and returned to the previous cue or patch. Participants often needed to backtrack for small changes, and this suggests supporting fine-grained backtracking that allows non-linear explorations of past programming history [8, 41].

## **5.5 Strategies followed when fixing bugs**

While fixing the bug, participants used *Enrichment, Navigation* and *Verification* strategies.

#### *5.5.1 Enrichment strategy*

Participants searched for all possible cues that led them to fixes for the bugs and aggregated them. Most participants used Google to find the solution for bug fixes. They temporarily collected information to reduce cognitive efforts. For example, participants copied original URLs into the notepad and then started making changes to the pipe programs. Hence, supporting to-do lists can help end-user programmers to complete their tasks systematically [61]. Participants also kept the documents (web document and IDE) open side-by-side like when they searched for bugs, necessitating support for multi-contextual views for code and relevant web pages.

#### *5.5.2 Navigational strategy*

The participants skimmed through patches for stronger scents. They used already visited patches as negative evidence in their foraging pursuits. For example, participants closed the web pages immediately when they realized they had already visited them. This prompted the participants to backtrack often to previous cues or patches as they were no longer foraging in the right directions. This suggests the need of tools that allow backtracking across multiple patches.

#### *5.5.3 Verification strategy*

After fixing the bugs, participants verified it by rerunning the pipe programs and comparing the output to the given solution (oracle). Verification is a very important step in software engineering and building automated techniques to support verification for end-user programmers can help them produce better quality software applications.

### **6. Conclusions**

Our analysis of the debugging behavior of eight end-user participants using information foraging theory suggests that clear cues were the most cost-effective method for finding bugs in mashup environments. Clear cues created stronger perceived value and helped more in the debugging process allowing end-user programmers to locate bugs more easily when compared to fuzzy or elusive cues. Fuzzy and elusive cues resulted in a hindered debugging progress as end-users would end up in useless patches. In addition, the presence of sub-pipes added additional complexity

#### *How Do Web-Active End-User Programmers Forage? DOI: http://dx.doi.org/10.5772/intechopen.97765*

to the debugging process as participants were unsure where cues were coming from, even if they were clear. Our study also examined how the participants followed the cues to find solutions to the present bugs.

The participants used three main strategies to locate bugs: hunting, navigation, and enrichment. While hunting they used a depth-first strategy resulting in a persistent pursuit of a single bug. When navigating the participants would use the dataflow structure of the program to perceive the value of the bug's location and would backtrack through relevant program histories to locate the bug. Finally, when using the enrichment strategy, participants would organize their environment by placing their IDE side by side with a web browser or by rearranging the code for easier foraging.

The presence of relevant error messages made these strategies for finding bugs more effective; however, when fixing the bugs by foraging the web different strategies were needed in the absence of clear cues. The participants made use of enrichment, navigation, and verification strategies for fixing bugs. They enriched their patches by finding relevant information through Google, storing URLs of useful websites, and by having these resources open side by side next to the editor. The participants navigated the web and used negative evidence to avoid already visited webpages or unhelpful resources. Then by running the program after implementing fixes, the participants would verify that their solutions fixed the bugs.

Our results suggest mashup programming environments need to facilitate clear clues and support hunting, enrichment, navigational, and verification strategies to facilitate the debugging process for end-user programmers.
