Inversion : How to fail at implementing a web scale discovery service

I’ve recently come across an idea known as inversion. We generally think in this way, “What do we do to reach goal X ?” Inversion is the idea that often it is of great value to invert the problem, in this case think “What do we do if we want to fail to reach goal X?”

This has value because often

Avoiding stupidity is easier than seeking brilliance.

In Inversion: How Smart People Consistently Avoid Looking Dumb, the article recommends the following steps

1. Define the problem you’re trying to solve.
2. Invert the problem to clarify what you don’t want to happen.
3. Avoid what you don’t want to happen.

How would I use this for library work?

I’m currently considering the implementations of data repositories for institutions but I’ll start with a easier topic — “How to fail at implementing a web scale discovery service.” Easier because I have lead 2 Web scale discovery services and have suffered through the pains of such projects.

The first thing that occurs to me is the similarity of title to the now famous “How to Scuttle a Scholarly Communication Initiative” article by Dorothea Salo.

The main difference I think is that article was written as a tongue in the cheek satire piece, which I think isn’t quite the aim of inverted thinking.

That said it seems in the course of writing I naturally slip into tongue in the cheek manner anyway

So without ado let me begin

How to fail at implementing a web scale discovery service

1. Ignore testing of common known item searches, everyone knows that discovery is about topic search
2. Related, trust the relevancy system, include as much content as possible available in the results — more is better! People who whine about book reviews & newspaper articles flooding the search have no idea what they are talking about.
3. Focus testing on STEM people, Humantities people won’t like it anyway. Extra points if you intend to take way the classic catalog and replace it only with the Discovery service.
4. Web Scale Discovery is for undergraduates only , nobody uses advanced search hence there is no need to test it
5. Data quality issues are never a problem just import the catalog and that’s good enough most of the time. Extra points if you have a lot of non-english content.
6. If you are also switching knowledgebases and link resolvers to work with your discovery service, don’t worry about budgeting time on that, populating and configuring them is a piece of cake — spend more time on the discovery service instead.
7. Avoid including front facing librarians particularly liasons and IL librarians in the process, it’s a waste of time, as the service is going to be the default search in the library website and they have no choice but to use and teach it anyway.
8. Definitely use the defaults for the Discovery service and link resolvers, there is no need to do use UX testing to change anything. The defaults are obviously the best suited for most cases — that’s why they are the defaults!

Conclusion

Not sure if I succeeded in my goal, though it was an interesting exercise. Next is to try with something I have no experience in at all and see how well it works….