Collaborative Drug Discovery (CDD) held its third Community Meeting at The J. David Gladstone Institutes at UCSF’s Mission Bay campus last week. This well-attended meeting brought together an unusual mix of biomedical researchers and assorted computational types to mingle with foundations, biotechs and pharmas, all to discuss how CDD’s unique technology has helped them tackle orphan or under-studied diseases such as malaria and tuberculosis.

Because facilitating collaborative research is one of ResearchScorecard’s core goals, I made a point of attending, as well as presenting a poster.  In brief, our message was simply that our tools can help identify and assess potential collaborators, something which is especially important in the realm of orphan diseases, where researchers may not be well-integrated with areas of research with greater representation.

Interestingly for me, another expertise location system was also presented in poster form by Dr. Kate Marusina from UC Davis’ Clinical and Translational Science Center. Specifically, she and her colleagues have been developing a CTSA Pharmaceutical Assets Portal using a data mining-intensive approach similar to ResearchScorecard’s.  Their goal is to help “… forge relationships with the pharmaceutical/biotech industry with the intent to facilitate the transfer of the investigational drugs and biologics for academic research”. This, of course, is a variant of ResearchScorecard’s goal, and I was thrilled to discover the interesting way they’ve been going at it. Going forward, you can expect to see their influence upon ResearchScorecard (emulation being the sincerest form of flattery, you know). More on their work in a subsequent blog.

Now, if you’re not familiar with CDD, you would do well to check them out. At its simplest, they have married Web 2.0 groupware functionality with traditional compound screening capabilities such as registration, data analysis and visualization, and protocol management. Some of the very impressive features of CDD’s tool are the exceptional flexibility, ease of use and speed they offer over tools from traditional vendors such as MDL and others. It has to be seen to be believed, and CDD’s CEO, Dr. Barry Bunin, gave a mind-blowing demo of the improvements they’ve made over the last year. OK, it’s mind-blowing only if you’re a software geek, but hey, I know for a fact that the kinds of operations performed in seconds by CDD used to take anywhere from minutes to days, if they were possible at all.

So how do they do it? Their software is written using the Ruby language following the agile methodology, complete with unit testing for all components and generating “builds” automatically, thus enabling rapid progress. Having worked in the scientific software field, I can tell you there are very few companies that follow such a rigorous process. The upshot is that not only is CDD’s software remarkably bug-free, but their productivity appears excellent. That’s a hard combination to achieve in any field, scientific or otherwise.

Consequently, I’ve now officially joined the ranks of believers in Ruby on Rails (RR), at least when it comes to scientific software. Why? Because building such software has traditionally lagged way behind experimentation, creating constant frustrations with the biologists and chemists who depend on the software keeping up with them. As far as I can tell, RR is as big a step-up in facilitating the development of bio- and chemoinformatics software as Perl was in the early ’90s, namely, a 10X over writing software in the standard language and approach of the day: endless compilations of programs written in C, ouch.  Within certain parameters, I believe CDD has proven that Ruby is well-suited for even compute-heavy scientific applications.