Let’s keep talking about the web, which is what I mostly do on my blog, and dive into 7 ways you can avoid your Lucene/Solr implemention fails. Having content that no one can find, not even your own users, is useless. Every Web CMS project and company has to face this issue at some point. What to do about search? This is where Lucene/Solr comes into the picture.

The information below comes from the CMSWire online magazine website.

CMSWire spoke with Lucene/Solr expert Jay Hill of Lucid Imagination for a few tips on things to avoid when implementing Lucene/Solr to reduce the risk of your search project biting the dust. Hill calls them the “Seven Deadly Sins of Solr” – sloth, greed, pride, lust, envy, gluttony and wrath.

1. Sloth

According to Hill, sloth is one of the worst things you can do — or rather not do — when implementing Lucene/Solr. Sloth, or laziness, is about failing to make the effort necessary to ensure an implementation is successful. Sloth can come in many forms:

• Failing to understand the features, strengths and weakness of Lucene/Slor
• Not tuning the application, Java Virtual Machine or server
• Not taking time to understand user needs
• Relying exclusively on consultants to implement the solution

Adopting enterprise search is complicated, and sloth will cause your project to fail.

2. Greed

Greed is another common mistake organizations make when implementing Lucene/Solr. Many assume that because Lucene/Solr is free open source, it will cost nothing to implement. The solution costs less than comparable commercial enterprise search options, but implementation is not free. Hill said, he has seen many companies try to implement Lucene/Solr “on the cheap” at the expense of their entire project. If you want to implement enterprise search you should be prepared to invest in items like an adequate number of servers, professional services for implementation guidance and training.

3. Pride

Pride can be a good thing, but take it too far and it becomes arrogance, which is rarely a positive trait. That is definitely true when it comes to implementing Lucene/Solr.  Excessive pride is indicated by actions like failing to get help when you encounter a problem, assuming you know the business requirements instead of soliciting them from the users or custom coding features/solving problems that others have already addressed. Pride can result in excess expense, time and effort to implement Lucene/Solr.

To avoid your project being negatively impacted by pride:

• Ask for help or use resources like the user and developer mailing list to find solutions to implementation, management or design issues
• Let the users define project needs instead of building in too few or too many features based on your assumptions
• Participate in the Lucene/Solr community and respect the experience of others
• Admit to yourself that although your project has unique features, other projects have similarities. Don’t be afraid to leverage the knowledge that others have learned from their implementations.

4. Lust

Most technologists have experienced techno lust at one point in their career. However, you have to keep in mind that the bleeding edge is called the “bleeding” edge for a reason. You will eventually experience pain if you lust after new feature and implement it prematurely or without adequate justification. Other examples of lust in Lucene/Solr implementations include:

• Jumping into an overly complex infrastructure before understanding your actual query volume
• Trying to do too much at once. It is often better to pursue iterative approach to implementation so that you can adjust as you learn lessons
• Obsessing over minute details before dealing with fundamental project issues
• Trying to push the envelope just because it’s cool

Lust introduces unnecessary risk into your project, which could easily extend budgets and timelines, or worse, cause the project to fail. When implementing Lucene/Solr, or any other enterprise search solution, it’s better to use an agile approach, do adequate due diligence before attempting cutting edge unorthodox approaches and focus on core requirements, design and implementation.