larlet-fr-david-cache/cache/626468d153ec2e83731dbbd7133af224/index.md

title: Falsehoods Programmers Believe About Search
url: https://opensourceconnections.com/blog/2019/05/29/falsehoods-programmers-believe-about-search/
hash_url: 626468d153ec2e83731dbbd7133af224

<p>As much as anyone I’m a fan of resurrecting trends and memes and pretending it’s cool.  In that vein dear friends, I’ve exhumed the venerable “Falsehoods Programmers Believe” party from 4 years ago to bring you one about, no less, Search.</p>

<p>Search is a deceptively complex field, where competence is hard-won through training, practice, and experience.  The list stands at a total of 105 falsehoods.  I couldn’t mash up the ole 99-problems meme with this to cull 6 unworthy items, because they are all worthy.  I will leave you with that brief introduction and, of course, the list:</p>

<ul>
  <li>Search engines work like databases</li>
  <li>Search can be considered an additional feature just like any other</li>
  <li>Search can be added as a well performing feature to your existing product quickly</li>
  <li>Search can be added as a well performing feature to your existing product with reasonable effort</li>
  <li>Choosing the correct search engine is easy and you will always be happy with your decision</li>
  <li>Once setup, search will work the same way forever</li>
  <li>Once setup, search will work the same way for a while</li>
  <li>Once setup, search will work the same way for the next week</li>
  <li>The default search engine settings will deliver a good search experience</li>
  <li>Customers know what they are looking for</li>
  <li>Customers who know what they are looking for will search for it in the way you expect</li>
  <li>Customers who don’t know what they are looking for will search accordingly</li>
  <li>A customer using the same query twice expects the same results for both searches</li>
  <li>Customers only search for a few terms</li>
  <li>Customers only search for less than some set number of terms</li>
  <li>Customers never copy and paste a whole document into a search bar</li>
  <li>Customers balance quotes and parenthesis</li>
  <li>Customers that don’t balance quotes or parenthesis don’t expect phrasing or grouping</li>
  <li>You can pass the customer query directly into your search engine</li>
  <li>You can write a query parser that will always parse the query successfully</li>
  <li>You will never have to return a query parse error to the customer</li>
  <li>When you find the boolean operator ‘OR’, you always know it doesn’t mean Oregon</li>
  <li>Customers notice their own misspellings</li>
  <li>Customers don’t expect your search to correct misspellings</li>
  <li>It is possible to create a list of all misspellings</li>
  <li>It is possible to create an algorithm to handle all misspellings</li>
  <li>A misspelled word is never the same as another correctly spelled word</li>
  <li>All customers expect spelling correction to work the same</li>
  <li>All customers want their misspellings corrected</li>
  <li>A search should always return results, no matter how absurd</li>
  <li>If you don’t have any results to show, customers won’t mind</li>
  <li>When the perfect results are shown to the customer, they will notice it</li>
  <li>You don’t need to monitor search queries, results, and clicks</li>
  <li>Customers won’t get nervous that you are logging their search activity</li>
  <li>Search queries are not affected by GDPR</li>
  <li>Looking at the data, it is always possible to tell whether a customer found what they were looking for</li>
  <li>Customers will click on what they are looking for when they’ve found it</li>
  <li>You can build a search that works like Google</li>
  <li>You can build a search that works like Google sometimes</li>
  <li>You should use Google as a target for your search</li>
  <li>Customers don’t mind if your search doesn’t work like Google</li>
  <li>Customers don’t expect your search to work like Google</li>
  <li>Customers won’t compare you to Google</li>
  <li>A bad search, no matter how minor nor how rare, will never reflect poorly on your product</li>
  <li>Since Google doesn’t use facets, customers don’t need them</li>
  <li>Facet hit counts are always correct</li>
  <li>Facets have no impact on performance</li>
  <li>You can just cache queries to get performant facets</li>
  <li>Personalized search is easy</li>
  <li>Learning to rank is easy and just requires a plugin</li>
  <li>You have enough data for learning-to-rank</li>
  <li>Over time, you can curate enough data for learning-to-rank</li>
  <li>You don’t need to spend lots of time formatting content for it to work well in your search engine</li>
  <li>Text extraction engines will always produce text that doesn’t need to be post-processed</li>
  <li>All your markup will be stripped as you expect it to be</li>
  <li>Content is well formed</li>
  <li>Content is mostly well formed</li>
  <li>Content is predictably well formed</li>
  <li>Content, sourced from a database and templates, are formed the same</li>
  <li>Content teams treat search as their top priority</li>
  <li>Manually changing content to improve search is easy</li>
  <li>Improving content can be automated with reasonable effort</li>
  <li>Queries for ‘C programming’ and ‘C++ programming’ will produce different results</li>
  <li>Queries for ‘401k’ and ‘401(k)’ will produce the same results</li>
  <li>Tokenization as it works out of the box is right for your content and queries</li>
  <li>Tokenization can be changed to meet the needs of your entire corpus and all queries</li>
  <li>Tokenization can be changed to meet the needs of most of your corpus and most queries</li>
  <li>Tokenization can be conditional</li>
  <li>You should roll your own tokenizer</li>
  <li>You will never have a debate about tokenization</li>
  <li>Regular Expressions for tokenization is a good idea</li>
  <li>Regular Expressions have minimal performance impact</li>
  <li>You will never have a debate about regular expressions</li>
  <li>You should remove stop words</li>
  <li>You should not remove stop words</li>
  <li>You know what the list of stop words should be</li>
  <li>Stop words will never change</li>
  <li>When you find the stopword ‘in’, you know it doesn’t mean Indiana</li>
  <li>It’s easy to make certain things case sensitive</li>
  <li>Case sensitivity is a good idea</li>
  <li>Synonyms are easy</li>
  <li>Synonyms will improve recall in the way you want</li>
  <li>Synonyms have the same relevance in all documents</li>
  <li>Synonyms for Abbreviations and Acronyms always work as you expect</li>
  <li>Synonyms can be extracted from your corpus with natural language processing</li>
  <li>Using Word2Vec for synonyms is a good idea</li>
  <li>Stemming will solve your recall problems</li>
  <li>Lemmatization will solve your recall problems</li>
  <li>Lemmatization dictionaries are static</li>
  <li>Languages don’t change</li>
  <li>Natural language processing (NLP) tools work perfectly</li>
  <li>Incorporating NLP into your analysis pipeline is straightforward</li>
  <li>Search queries are complete sentences and can be accurately tagged with parts of speech</li>
  <li>Showing a list of search suggestions is easy</li>
  <li>Suggestions should just use the out of the box search engine suggestions</li>
  <li>Suggestions should incorporate customer query logs</li>
  <li>Customers would never type anything offensive into your search bar</li>
  <li>Customers would never try to hack you through your search bar</li>
  <li>Customers don’t need highlighting to find what they’ve searched for</li>
  <li>Default highlighters are good enough for all your content and queries</li>
  <li>Making a custom highlighter isn’t too difficult.  It’s just matching strings right?</li>
  <li>Making a custom highlighter that is better than the default version will take less than a year</li>
  <li>Turning on caching will solve your performance issues</li>
  <li>Customers don’t expect near real time updates</li>
  <li>30 second commit time is short enough for everyone</li>
</ul>