The Internet plays a key role in accomplishing many tasks. To use internet for task completion, web search is integral in finding relevant information. The typical knowledge worker frequently searches for experts, information, and tools to help with their work (Reinhardt et al., 2011). In software engineering (SE), web search is heavily used to help with various tasks such as debugging, finding API usage (Nasehi et al., 2012) or examples (Brandt et al., 2010; Stylos and Myers, 2006), navigating to resources, etc. Previous work has extensively studied several aspects of web search usage and user behavior as well as Web search usage across demographics (see Section 2 for details). While there has been some work on Web Search Usage in domains such as e-commerce, little is known about how Web search is used in software development. Several papers looked into how software engineers search for code specifically (Bajracharya and Lopes, 2012; Stolee et al., 2014; Sadowski et al., 2015) and many tools have been built to facilitate code search (Bajracharya et al., 2006; Martie et al., 2017; Kim et al., 2018; Holmes, 2009; Rahman et al., 2018). However, software engineers use web search for more than just code. They often search for bug fixes, tools, documentation, discussions, and more (Xia et al., 2017). The most definite work so far on how software engineers search on the Web is by Xin et al. (Xia et al., 2017) who collected search logs from 60 developers and interviewed 12 software engineers to categorize search tasks and assess the the difficulty and frequency of these search tasks.
In this paper, we present the results from a large scale study of millions of search queries and sessions from a major commercial web search engine (Section 3). To learn more about how web search is used in software engineering, we have built a classifier that recognizes SE-related queries with high accuracy. We then identified a taxonomy of intents for why software engineers search on the Web. Lastly, we compare how SE queries are different from non-SE queries. This is the first large scale study to analyze web search usage for SE tasks and not just code search. Specifically, we make the following main contributions:
We propose a machine learning based method for distinguishing software engineering related search queries from other queries. Our evaluation shows that the classifier has high accuracy. (Section 4)
We define a taxonomy of intents behind the web searches of software engineers. The taxonomy includes the following intents: queries related to debugging, how-tos, learning, APIs, and installation as well as navigational queries. (Section 5)
We present the results from a large-scale analysis using the query logs of a major commercial web search engine. We characterize and compare how software engineering related search queries and sessions are different from other queries and sessions. (Section 6)
2. Related work
There have been a significant amount of work from the data mining and information retrieval communities around characterizing and improving Web Search. In this work, we leverage insights and metrics from this work to better understand web search in context of software engineering. In the empirical software engineering community, the primary focus has been on analyzing code search by developers. In this section, we discuss related work from all these areas.
2.1. Web search query understanding
Previous work has extensively studied several aspects of Web search usage and user behavior while using Web search. For instance, previous work has studied how users behave with respect to several characteristics of Web search queries. Ong et al. (Ong et al., 2017) studied different user behavior for Mobile search and Desktop search queries; highlighting several usages differences on the type of queries and the interaction with the results. Other work focused on characteristics of the results such as the effect of snippet length and content (Maxwell et al., 2017) and the effect of the number of documents in the result list (Kelly and Azzopardi, 2015). Other studies focused on query characteristics such as the the query interface and query difficulty (Azzopardi et al., 2013). These studies are very generic in nature and aim to provide a general characterization of how people use and interact with Web search.
Previous work also tried to study Web search usages for more refined segments. For example Mehrotra et al. (Mehrotra et al., 2017) studied search engine usages across different ages, genders and other demographics. Additionally, the difficulty of the search task was also shown to have a significant impact on interactions with search engines (Aula et al., 2010; Kim et al., 2014). Even though, these studies try to study Web search usage in more defined segments, they create the segments based on domain independent factors such as demographics, task type or task difficulty. Another area of interest has been characterizing Web search usage for specific domains. For example, Jansen and Molina (Jansen and Molina, 2006) studied Web search usage in the e-commerce domain. More specifically, they evaluate the effectiveness of search engines in the retrieval of relevant e-commerce links. Web search for health and medical queries has also received significant attention (e.g. (Spink et al., 2004; Schoenherr and White, 2014)). Spink et al. (Spink et al., 2004) provided general characterization of medical and health queries; showing that the top five categories of medical or health queries were: general health, weight issues, reproductive health and puberty, pregnancy/obstetrics, and human relationships. It also compares usage of general Web search vs. specialized medical/health websites for finding health related information.
In this work, we build on previous work on characterization of web search engine usage. Unlike previous work, we focus on search engine usage for software engineering tasks. Additionally, we discuss implications of this characterization on how to improve existing tools and build new tools to better support software engineering tasks.
2.2. Code search
In software engineering community, there has been significant amount of work in understanding and improving code search (Bajracharya et al., 2006), (Martie et al., 2017), (Kim et al., 2018), (Holmes, 2009). Bajracharya et al. (Bajracharya and Lopes, 2012) analyzed usage of Koders.com, a specialized code search engine, by developers. They do a lexical analysis of the search queries and also use topic modelling to extract 50 topics from the search queries. Similarly, Stolee et al. (Stolee et al., 2014) surveyed developers on the tools used for code search and found that 69% of the participants use Web Search for code search and the existing code search tools were not satisfactory. (Sadowski et al., 2015) studied code search by developers at Google. They surveyed 27 developers to understand the intent behind code search and also the properties of code search queries. Perhaps the closest work to our work is the study by Xia et al. (Xia et al., 2017). They collected search logs from 60 developers and interviewed 12 software engineers to categorize search tasks into 34 buckets across seven different categories. They also carried out a survey to understand the difficulty and frequency of these search tasks. They also found that developers are more likely to search for code on web search engines than on specialized code search engines. This supports our work by showing the importance of web search engines in software engineering.
Our work differs from existing work in the software engineering community in several aspects: a) Ours is the first large scale study to analyze web search usage for SE tasks and not just code search. As we discuss in Section 5, web search is used for multiple other SE related tasks like navigation, learning and installation. Similarly, by using the search logs from a major web search engine, we are able to analyze a large set of population without limiting ourselves to developers in a commercial setting. b) We propose a novel method for labeling search queries for SE tasks and train a ML classifier for classifying SE queries. c) We also carry out a large scale study on millions of search queries and sessions to understand how they differ in key Web Search metrics.
3. Web search logs
In this paper, we leverage the web search logs from a major commercial search engine. The search engines logs a rich set of metadata for all the search queries made by the users. In this work, we leverage a subset of them described below, for our study. Also, the search logs have been anonymized to remove any user identifiable information before any analysis was conducted.
Below, we define some of the terms that will be used throughout the paper:
Search query: A search query is the raw query text entered into the search engine by the users.
Client: A client is a user facing application used for browsing the search engine and doing search queries. Clients are uniquely identified by using various tracking mechanisms, for instance, browser cookies.
Search session: A search session is a group of queries and clicks from a given client delineated by a 30 min inactivity period (Radlinski and Joachims, 2005).
Result Urls: Ordered list of Urls displayed by the search engine in response to the user query.
Click Urls: List of Urls which were clicked on by the user from the Result Urls.
Dwell time: Time spent by a user on a clicked result page. Dwell time has a high correlation with the relevance & satisfaction of the result page to the user (Fox et al., 2005).
SAT (satisfcation) clicks: Click Urls with dwell time ¿ 30 sec. As Fox et al. (Fox et al., 2005) proposed, a clicked result is relevant to the search query if the user spends more than 30 seconds on the clicked page, which is a significant amount of time.
3.2. Data filters
Web search is used from a wide variety of demographics, locales, clients, etc. The search usage patterns may vary heavily based on these parameters. So, we filter the query traffic to remove any variability & noise due to factors such as languages, geography and client form-factors.
Locale & region - We only use search logs from users with English locale and from the US region. We also filter out any search queries which contain non-English characters by checking for non-ASCII characters.
Clients & traffic sources - Since we are focusing on analyzing real user behavior, we filter out automated traffic from bots and services which query the search engine via APIs. Lastly, as Kamwar et al. (Kamvar and Baluja, 2006) have showed, web search patterns and usage differ vastly between different client form factors like desktop, mobile, etc. Since the majority of tasks related to SE are carried out on desktop, we only focus on search traffic from desktop clients in this study.
4. Query Classification
In order to understand how web search is used for software engineering, we first need to be able to distinguish SE related search queries from other queries. In this study, we refer to a query as a software engineering related query if the query relates to any software related task such as debugging, how-to, downloading or installing a software, etc. We discuss the various software related web search tasks in detail in Section 5.
4.1. Inferring labels
|github.com||Largest collaborative software development platform|
|developer.mozilla.org||Documentation for web standards & Mozilla projects|
|docs.oracle.com||Documentation for Oracle products including Java|
|developer.android.com||Official website for Android applications and OS|
|stackoverflow.com||One of the most popular Q&A website for programmers|
The main challenge in building a classifier is getting labeled data. To build a machine learning based classifier, we will need significant amount of labeled data containing both software engineering related search queries and non software engineering related search queries. So, we propose a semi-supervised way to build our training dataset. For this, we leverage Alexa.com (Alexa.com, 2019) website listings and the click information from the query logs. Alexa.com ranks the top websites based on country and category. Here are the details of the steps we followed:
We collected 5 SE related websites from the software category on Alexa.com.
We process 5 days of the query logs described in Section 3 and extract 1 million queries. We discuss the data sampling process in detail in Section 4.2.
Subsequently, we label the randomly sampled queries as non-SE related and the ones with at least one click on a SE-related domain (listed in Table 1) as SE related.
The key insight we leverage here is that the queries which lead to click on the SE related domains are generic and diverse enough to train a more general classifier for all SE related queries. The efficacy of this method is confirmed by the evaluation results. One optimization we did is to remove navigational queries from the data by removing queries which resulted in a click to the home page of the SE domains. Additionally, instead of just relying on the heuristics, we decided to train a classifier because of two reasons (a) Not all the queries leading to clicks to these websites will be SE related, for instance, the queries for login and financial statements, (b) The 5 SE related websites form a small subset of the SE related websites.
As described earlier, we have access to rich set of metadata for search queries such as the query text, result Urls, clicked Urls, dwell times, etc. However, we only use the features derived from the query text for training the classifier, so that we can classify queries even when other information is absent. For instance, not all queries lead to clicks on the search results. Also, since our heuristics rely on the clicked Urls, we explicitly remove that from the model features to prevent information leak. Before extracting features from the query text, we pre-process the text by replacing non-alphanumeric characters with space. We then transform the query text into a vector representation by first extracting a token count vector and then transforming it to a TF-IDF representation. TF-IDF representation helps reduce the weightage of frequently occurring words such as stop words.
For training and testing of ML classifiers, we sample 2 million search queries from April 1st, 2019 to April 5th, 2019. We restrict the queries to en-US and normal traffic as described in Section 3. These queries are sampled in a stratified manner with 1:3 ratio of SE:Non-SE queries. We decided to do stratified sampling instead of random sampling because SE queries form a small fraction of the overall web search traffic. So, effectively our train and test data contains 1.5 million non-SE and 0.5 million SE queries. Finally, we do a 70:30 random split of the data for the train and test datasets.
4.3. Model selection
We formulate the task of distinguishing SE and non-SE queries as a binary classification problem. In order to select the best machine learning algorithm, we experiment with 4 commonly used ML based classifiers: AdaBoost, Decision Trees, Logistic Regression, Linear SVC (Support Vector Classification). For training and evaluation the classifiers, we use the Scikit-learn 0.20.0 package for Python 3.7.1. Note that our goal is not to find the best-fitting classifier, but to explore the feasibility of classifying SE related search queries. So, we use the default hyper-parameters for these classifiers.
To compare the classifiers, we use 4 metrics: Precision, Recall, F1 and AUC. These metrics are widely used for classification tasks. Here, AUC is the area under the ROC curve, which measures the overall discrimination ability of a classifier. It has been widely used to evaluate classification algorithms in prediction tasks (Reinhardt et al., 2011). A machine learning model is considered applicable to classify a given dataset, if the AUC score is larger than 0.7. Following existing studies (Kohavi and others, 1995), we use the widely used 10-fold cross-validation to evaluate the classification models. Table 2 shows the metrics for each of the classifier. As we can see, the LinearSVC classifier clearly outperforms all the other models. Also, all the classifiers achieve AUC score more than 0.7. LinearSVC achieves a F1-score of 0.93 and an AUC of 0.989. Based on these results, we chose the LinearSVC model for classification of SE and non-SE queries and do further evaluation in next section.
4.4. Model evaluation
In this section we evaluate the efficacy of the LinearSVC model for classifying SE and non-SE queries. Firstly, we do further analysis of the model on the automatically labeled test dataset described in the previous section. Secondly, we do an evaluation of the model on manually annotated data. Lastly, we do a qualitative analysis of the feature weights learnt by the model to show that it’s highly generic.
Evaluation on inferred labels - As shown in Table 2. the LinearSVC model has high accuracy on the test data created using the inferred labels as described in Section 4.1. Since, the data has a class imbalance, we also separately computed the metrics for both SE and non-SE classes. The metrics are shown in Table 3. Here, support refers to the number of samples that belong to a given class. As we can see, for both the classes, the LinearSVC model has ¿ 0.93 F1-score. This shows the model can classify both SE and non-SE queries in the test set with high accuracy.
Manual evaluation - The evaluation we have done so far was based on the automatically labeled dataset. It’s plausible that the ML classifier simply learns to distinguish search queries from the SE websites listed in Table 1 vs queries from other websites.
So, we did a manual evaluation, where we randomly sampled 200 search queries from the test dataset. Then, two of the authors manually and independently annotated the data with SE and non-SE categories. We used Cohen Kappa (Cohen, 1960) coefficient to measure the inter-rate agreement and the score was 0.91. Finally, we evaluated the accuracy of the ML model on this dataset and the accuracy was 0.93 which proves that the model is generic and highly accurate.
- For training the ML classifier we used the unigram features extracted from the search queries. To further analyze the model, we looked at the top 20 features, shown in Figure1, and their coefficients learned by the model. Both the positively (for instance: python, github, string) and negatively correlated features (for instance: county, news, porn) were very generic. Also, they have a clear mapping to SE and non-SE topics respectively.
5. Query taxonomy
There are many reasons why software developers search the web, for example to learn more about a technology or to debug an error message they encountered. To better understand the motivations behind web searches related to software technologies and to derive an initial taxonomy of search intent, we manually labelled three sets of search queries. Each dataset contained the query and the URLs that the user clicked on (if any) for 50 web searches. When needed, the raters searched for the query and considered the entire search results. In total, we labelled 150 search queries.
We randomly selected 50 queries that contained the term “TensorFlow”. This dataset was labelled independently by two raters who followed an open coding approach, i.e., rather than predefined labels, the labels emerging during the coding of the web searches. For each web search, exactly one category was assigned. The raters then met and discussed the categories and agreed on an initial set of categories:debug, how-to, installation, learn, navigational, and misc.
TensorFlow #2. This dataset of 50 web searches for “TensorFlow” was used to further validated the categories and to measure inter-rater agreement. Three raters independently labeled the dataset with the categories from the previous dataset. No new categories emerged. The pairwise Cohen Kappa agreement (Cohen, 1960) between the three raters was 0.469, 0.530, and 0.637; the Fleiss Kappa agreement (Fleiss, 1971) among all three raters was 0.545.
Xamarin. This dataset was used to validate the categories for a different technology. The dataset included 50 queries that contained the term “Xamarin”. Two raters independently labelled the dataset with the categories from the previous dataset. The Cohen Kappa agreement between the two raters was 0.524. For this dataset, a new category emerged: api for any searches related to documentation on how to use certain Xamarin APIs.
The agreement scores indicate a moderate agreement according to the classification by Landis and Koch (Landis and Koch, 1977). When the raters disagreed, this was either because of lack of context (“3559a tensorflow”, “tensorflow 1.13 rc0 .whl”) or for queries where multiple categoris were applicable (“tensorflow tools”). The resulting taxonomy is summarized in Table 4 and discussed below.
|Debug||Find information to debug an error or an issue|
|How-to||Find information to accomplish a specific SE related task|
|Learn||Find information to learn about a SE related topic|
|API||Navigate to information about a specific API element.|
|Navigational||Navigate to a specific web-page on a SE related topic|
|Installation||Install a software, tool, package, etc.|
|Misc||None of the above intents is suitable|
Debug. This category captures web searches that are related to debugging an error or issue. Typical searches include error messages (“tensorflow/core/framework/op.h: No such file or directory”), parts of stack traces (“Java org tensorflow lite NativeInterpreterWrapper createErrorReporter”), and sometimes a description of the context of the error (“xamarin SIGSEGV after upgrading to visual studio 2019”), which often can be short and abstract (“tensorflow1.3 MKL libdl.so.2”). For this type of query, users typically often click on StackOverflow search results, the respective issue trackers, and discussions in web forums.
How-to. This category captures web searches that are related to accomplishing a specific task with a software technology. These queries often contain a short description of what the user wants to accomplish ( “tensorflow get all tensors”
“tensorflow get all tensors”, “force tensorflow to use gpus”, “launch canera on camra button click in xamarin forms”) and in some cases the technology they want to use (“RandomShuffleQueue tensorflow”). For most of these queries, users click on StackOverflow results and when available official web forums and blogs.
Learn. This category captures queries related to learning about an abstract topic related to the software. Example queries are “tensorflow python tutorial”, “tensorflow tools”, “tensorflow deep learning”
“tensorflow deep learning”, or “xamarin testing”.
API. This category represents web searches where the user wants to learn more about a specific API element in the software. Searches related to specific API were much more frequent in Xamarin than in TensorFlow, hence we created a separate category. Examples are “xamarin.controls.signaturepad.forms” and “xamarin ActivityIndicator”.
Navigational. This category is related to queries where the search engine is used to navigate to a specific resource or web-page. Example queries are “TensorFlow: Large-scale machine learning on heterogeneous systems” and “o’reilly TensorFlow for Deep Learning”. In both cases, the user knew their destination and used the search engine as a shortcut/bookmark to get to a book or video respectively.
Installation. This category is for searches with the goal to install the software. Often these searches include the target environment (“tensorflow gpu keras 2019 windows 10”), version numbers, and simply the word download (“tensorflow 1.13 for windows download”). In many cases these searches end up at download or install pages on the official webpages but not always. For example, for the query “tensorflow gpu keras 2019 windows 10”
, the user clicked on a Medium.com post that in detail describe the nine steps necessary to setup the Keras deep learning framework on Windows 10 on both GPU and CPU systems. Interestingly searches related to installation were more common in our samples for TensorFlow than for Xamarin.
Misc. This category was used when none of the above intents was suitable or when insufficient context was available to make a decision. An example from this category is “3559a tensorflow”.
6. Query Analysis
In this section, we describe several metrics that we use to characterize search usage for software engineering. This includes characteristics of the queries, query reformulation and interactions with the search result pages. Also, we evaluate and compare these metrics for SE and non-SE queries on query logs. This helps us understand the differences in SE specific search tasks vs the regular search tasks.
For this analysis, we randomly sampled 1 million search sessions from the query logs between April 10th, 2019 and April 15th, 2019. The extracted logs contained queries from distinct clients. We have already discussed how sessions and clients are determined in Section 3. We have also applied the necessary filters as described in Section 3 to remove traffic from bots and also limit it to English locale and US geography. Further, we treat any search session with a majority of SE related queries as a SE related session. Hence, any session with at least 50% software engineering queries is classified as a software engineering related session. As we can see in Table 5, 2.61% of all the web search sessions in the sampled data are SE search sessions. This shows that web search is used significantly for SE related tasks.
|Unique Session %||2.611||97.389|
|Unique Client %||2.832||97.168|
|Avg. unique query count ( SEM)||2.186 ( 0.014)||3.05 ( 0.005)|
|Avg. similar query % ( SEM)||4.278 ( 0.072)||3.555 ( 0.01)|
|Avg. term addition count ( SEM)||2.484 ( 0.068)||2.183 ( 0.021)|
|Avg. term removal count ( SEM)||2.184 ( 0.085)||1.879 ( 0.025)|
|Avg. word count ( SEM)||5.245 ( 0.017)||3.807 ( 0.002)|
|Avg. character count ( SEM)||30.521 ( 0.0111)||24.088 ( 0.0163)|
|Avg. click count ( SEM)||0.41 ( 0.002)||0.449 ( 0.003)|
|Avg. SAT click count ( SEM)||0.217 ( 0.001)||0.236 ( 0.002)|
|Avg. total dwell time (in sec SEM)||270.051 ( 2.072)||307.549 ( 0.339)|
6.2. Query Characteristics
Number of Unique Queries
: The number of unique queries can serve as a metric for both query popularity and session length. Total number of unique queries provide a good estimate of how popular a given query estimate is. Additionally, a high number of unique queries per session could indicate that certain searches result in longer sessions. This could be an indication that the user needs to explore different aspects related to the information need or that the user needs to try multiple queries before the information need is met. We compute the distribution over the number of unique queries for different segments of queries. We used unique queries to avoid counting the same query multiple times when the user refreshes the search page or hits the back button. As we can see in Table5, SE search sessions contain on average 2.186 unique queries which is 28.33% lower than non-SE search sessions. This shows that the SE search sessions tend to be shorter than other sessions.
Also, we did an analysis of the word and character count. As we can see in Table 6, software engineering related queries have 37.8% higher word count on average compare to non-software engineering related queries. Based on our manual analysis, this can be attributed to majority of the queries being related to tasks like searching for error messages which tend to be more descriptive. Similarly, software engineering related search queries contain 27.17% more characters on average.
Query Similarity: One interesting characteristic of web search sessions may be the diversity of queries within the session. We might expect queries from a particular segment to contain less overlap as people revise their queries to explore alternatives. To examine this, we measure the similarity between every query in the session and the first query in the session. Our objective here is to assess how queries evolve as the user moves further into the session in both cases. Query similarity might also reflect how successful a user is with finding the needed information. If the user is struggling to find the information, we might expect strong resemblance to the first query to be present in future queries, but with terms being added or removed as the session proceeds.
To measure the similarity between pairs of queries in the session, we begin by performing standard text normalization where we lowercase the query text, replace all runs of white-space characters with a single space, remove leading or trailing spaces, and remove stop words. Thus every query is represented as a bag of non-stop word terms. The similarity between any two queries can be computed using the Jaccard coefficient between the two bags of word terms. As we can see in Table 5, SE search sessions contain 27.17% more similar search queries than other sessions. This means that in SE search sessions, user browse more about related topics.
Reformulation Strategies: The number of unique queries in a session and the similarity between queries shed light on the length of the sessions and how search progresses during the session.
Additionally, we also consider the strategies employed by the user when they transition from one query to another. Reformulated queries are pairs of queries that have similarity larger than a threshold. When a query is reformulated, the user might employ one or more strategies. For simplicity, we investigate the following strategies for moving between queries:
Term Addition: one or more words are added to the query
Term Removal: one or more words are removed from the query
As we can see in Table 5, software engineering related search sessions have a significantly higher rate of term additions and removals. This is consistent with our previous finding of software engineering related sessions having higher percentage of similar search queries as shown in Table 5.
6.3. Interaction Characteristics
Number of Clicks: We suspect that SE search sessions might have different click distribution compared to other sessions. This may be related to difference in task types or because users may experience different levels of difficulty locating information. Our dataset has logs of all clicks performed by the user during the search session. We excluded all non-result clicks (e.g., clicks on sponsored results), as well as clicks that lead to another search result page (e.g., spelling corrections, related search clicks, etc.). We then computed the average number of clicks for different query positions in the session for different segments. As shown in Table 6, SE search queries have a lower click rate and, also a lower SAT click rate than non-SE search queries. This can be attributed to SE related search tasks being more difficult than other search tasks.
Dwell Time: Another interesting question related to click characteristics is the difference in dwell time on clicked results. Dwell time is an important measure reflecting time spent by the user examining the clicked documents. Previous work has shown that the amount of time spent by users on the clicked document is an important indicator of whether they are satisfied with the content they encounter (Fox et al., 2005). Dwell time can be estimated from click logs by computing the time between the click and the next seen click or query on the search engine. We calculated the dwell time for every click in our dataset and then we calculated the dwell time per query averaging the dwell time of all clicks corresponding to a single query.
As we can see in Table 6, SE search queries have 13.8% less total dwell time on average than other queries. Longer dwell time has been shown to correlate with success in finding the required information. Hence, SE queries are less effective than other queries.
There are several implications of this work. First and most notably, the analysis of 1 million web search sessions in Section 6 suggests that software engineering related queries are less effective than other types of queries: we observed higher rates of query reformulations, fewer clicks, and shorter dwell time. Custom search engines could be a way to provide a better experience for software engineers. For example, we observed that software engineering sessions more often contain queries similar to other sessions, which suggests that other search sessions could improve the search experience. The query taxonomy presented in Section 5, can inform difference modes that search engines should support for software engineers.
On a large scale, search data also provides a pulse of what software engineers are searching for and what problems they face. This data can be analyzed to generate insight, for example identify frequent problems with software technology, compare the difficulty of different software technologies based on search query properties, or predict the satisfaction of developers with specific software technology, which are all avenues for future work. This information could be looped back to the creators and users of software technologies, similar to tools like Google Trends.
Lastly, the search history of individuals provides a wealth of information that can provide context for personal assistant like Siri, Cortana, etc. as well as software bots (Lebeuf et al., 2018). The search history can also be used for a personalized search experience and better software tools. Integrating context and task-aware search into software tools is another opportunity to improve their productivity. Search data can also be used as signal for task type detection (Bao et al., 2018).
In this paper, we presented the first large scale study on web search usage for software engineering. We demonstrated that it is possible to distinguish software engineering related search queries using machine learning without requiring any labeled data. Further, we showed that web search is mainly used in software engineering for 6 main tasks. These 6 category of tasks cover the majority of the software engineering queries. We further did a thorough analysis of a sample of 1 million web search sessions to better understand software engineering related search queries and sessions. We showed that software engineering related search queries and sessions constitutes a significant volume, over 2.6%, of the overall web search sessions. Lastly, we also found that software engineering related search tasks are less effective and require more effort than other search queries. We believe that these insights will be helpful in improving existing tools and building new tools for software engineers.
- Alexa - Top Sites. Note: https://www.alexa.com/topsites Cited by: §4.1.
- How does search behavior change as search becomes more difficult?. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, pp. 35–44. Cited by: §2.1.
- How query cost affects search behavior. In sigir, pp. 23–32. Cited by: §2.1.
- Analyzing and mining a code search engine usage log. Empirical Software Engineering 17 (4), pp. 424–466. External Links: Cited by: §1, §2.2.
Sourcerer: a search engine for open source code supporting structure-based search. In Companion to the 21st ACM SIGPLAN symposium on Object-oriented programming systems, languages, and applications, pp. 681–682. Cited by: §1, §2.2.
- Inference of development activities from interaction with uninstrumented applications. Empirical Software Engineering 23 (3), pp. 1313–1351. External Links: Cited by: §7.
- Example-centric programming: integrating web search into the development environment. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, pp. 513–522. Cited by: §1.
- A coefficient of agreement for nominal scales. Educational and psychological measurement 20 (1), pp. 37–46. Cited by: §4.4, 2nd item.
- Measuring nominal scale agreement among many raters.. Psychological bulletin 76 (5), pp. 378. Cited by: 2nd item.
- Evaluating implicit measures to improve web search. ACM Trans. Inf. Syst. 23 (2). Cited by: 6th item, 7th item, §6.3.
- Do developers search for source code examples using multiple facts?. In Proceedings of the 2009 ICSE Workshop on Search-Driven Development-Users, Infrastructure, Tools and Evaluation, pp. 13–16. Cited by: §1, §2.2.
- The effectiveness of web search engines for retrieving relevant ecommerce links. Inf. Process. Manage. 42 (4). Cited by: §2.1.
- A large scale study of wireless search behavior: google mobile search. In Proceedings of the SIGCHI conference on Human Factors in computing systems, pp. 701–709. Cited by: §3.2.
- How many results per page? a study of SERP size, search behavior and user experience. In sigir, pp. 183–192. Cited by: §2.1.
- F a c o y: a code-to-code search engine. In Proceedings of the 40th International Conference on Software Engineering, pp. 946–957. Cited by: §1, §2.2.
- Modeling dwell time to predict click-level satisfaction. In Proceedings of the 7th ACM international conference on Web search and data mining, pp. 193–202. Cited by: §2.1.
- A study of cross-validation and bootstrap for accuracy estimation and model selection. In Ijcai, Vol. 14, pp. 1137–1145. Cited by: §4.3.
- The measurement of observer agreement for categorical data. biometrics, pp. 159–174. Cited by: §5.
- Software bots. IEEE Software 35 (1), pp. 18–23. External Links: Cited by: §7.
- Understanding the impact of support for iteration on code search. In Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering, pp. 774–785. Cited by: §1, §2.2.
- A study of snippet length and informativeness: behaviour, performance and user experience. In sigir, pp. 135–144. Cited by: §2.1.
- Auditing search engines for differential satisfaction across demographics. In Proceedings of the 26th International Conference on World Wide Web Companion, WWW ’17 Companion. Cited by: §2.1.
- What makes a good code example?: a study of programming q&a in stackoverflow. In 2012 28th IEEE International Conference on Software Maintenance (ICSM), pp. 25–34. Cited by: §1.
- Using information scent to understand mobile and desktop web search behavior. In sigir, pp. 295–304. Cited by: §2.1.
- Query chains: learning to rank from implicit feedback. In Proceedings of the eleventh ACM SIGKDD international conference on Knowledge discovery in data mining, pp. 239–248. Cited by: 3rd item.
- Evaluating how developers use general-purpose web-search for code retrieval. In Proceedings of the 15th International Conference on Mining Software Repositories, MSR ’18, New York, NY, USA, pp. 465–475. External Links: Cited by: §1.
- Knowledge worker roles and actions—results of two empirical studies. Knowledge and Process Management 18 (3), pp. 150–174. Cited by: §1, §4.3.
- How developers search for code: a case study. In Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering, ESEC/FSE 2015, New York, NY, USA, pp. 191–201. External Links: Cited by: §1, §2.2.
- Interactions between health searchers and search engines. In Proceedings of the 37th International ACM SIGIR Conference on Research & Development in Information Retrieval, SIGIR ’14. External Links: Cited by: §2.1.
- A study of medical and health queries to web search engines. Health Information & Libraries Journal 21 (1), pp. 44–51. Cited by: §2.1.
- Solving the search for source code. ACM Trans. Softw. Eng. Methodol. 23 (3), pp. 26:1–26:45. External Links: Cited by: §1, §2.2.
- Mica: a web-search tool for finding api components and examples. In Visual Languages and Human-Centric Computing (VL/HCC’06), pp. 195–202. Cited by: §1.
- What do developers search for on the web?. Empirical Software Engineering 22, pp. . External Links: Cited by: §1, §2.2.