Comments on Stanford InfoBlog: An Often Ignored Collaboration Pitfall: Time Phase...

The mismatch being addressed in this blog entry is...

2008-12-08T10:15:00.000-08:00

The mismatch being addressed in this blog entry is one of the reasons I left academia for the "real world" (first Bell Labs, then a real software company, and now a quasi-research company). Being funded (partly) by an SBIR rather than a research grant lets me add the bells and whistles to software without worrying about whether it's publishable as new.

There's some benefit to a researcher's career from releasing software that works. I did this back when I was an academic at Carnegie Mellon. You get lots of citations, you get invited to things, and lots of people want to bounce ideas off of your. These are all tangible benefits to academics.

Statisticians often release their source at places like CRAN (the R archive). For instance, I'm digging through Douglas Bates's linear mixed effects package in R today and tomorrow, and it's nicely documented both in code and technical materials. It has lots of users.

The benefits from writing software are comparable to what you get from writing textbooks. Sure, it's not research per se, but it provides citations, and if it's a good book, an air of authority. And you also get a tool you can use for teaching. Not to mention being forced to organize your ideas more coherently.

I don't find too many Ph.D.-level computer science students who actually know how to code. Sure, they can cobble things together to get things to work, and build some amazing algorithms. But this is different than having the discipline to write professional software, which isn't any harder to write, just different. Two years as a professional C coder in speech recognition between Bell Labs and my current gig showed me just how much I had to learn. I'm guessing with all the open source out there that folks are at least getting better at things like source control and reading other people's code.

I could imagine Ryan's idea working. Two issues to...

2008-11-24T22:57:00.000-08:00

I could imagine Ryan's idea working. Two issues to consider,
though. It would be important that the receiving iSchool has its own
goals around the respective project, which would (i) further the
iSchool's special educational and research agenda, and would (ii)
still harmonize with the partner's goals. Otherwise it would be
difficult to maintain the required level of resource
investment. Ryan's example of deployment study does fit that shoe. Of
course, the iSchool would need early enough involvement that the
principle developers are still around for the transfer.

The second issue concerns the dealings with the collaboration
partner. Good collaboration requires some trust. Not trust in the
sense of honesty, but in the sense of belief that the other side is
truly interested in furthering both of the involved agendas, and that
credit is properly shared.

Developing such a working relationship takes some time and
effort. Passing a partner on to a whole new (and physically remote)
set of players, namely the iSchool team, would require special care
again.

Nice, thoughtful piece, Andreas! As I was reading,...

2008-11-24T21:00:00.000-08:00

Nice, thoughtful piece, Andreas! As I was reading, I was wondering: "what are the solutions?" as I scrolled down and found your solutions discussion. And then, "what is the role of the funding agencies"? And that came along, too...

While I somewhat agree with Ryan's point above, I don't think i-schools can follow through with all such projects (perhaps not even those conceived in an i-school), important as they may be. There's just not enough development power.

Maybe the department has to play a role? For instance, a CS department in, say, Stanford University (or some better school) could have a staff of 4-5 "research engineers", as they would call them in industry. The engineers will be hired by the department but budgeted from the various faculty grants and deployed as needed; those grants will include an implementation phase that would be handled by this in-house team. The benefits, of course, are mainly in having a reliable team of engineers that have a somewhat-permanent position instead of being hired per-project. Projects can be transferred to this team for development and maintenance, and will be expired/commercialized when appropriate. I think the NSF might be happy to add $100K for 6 months of developer time for project proposals, as these extra funds might add to the "broader impact" goals.

I think you've overlooked an important potential t...

2008-11-09T10:00:00.000-08:00

I think you've overlooked an important potential third-party in collaborations like these: the faculty and students of information schools and similar interdisciplinary programs. I-school researchers are often specifically interested in the innovation process by which existing inventions are adopted by specific communities or by which specific users are enrolled in a technological program surrounding that invention. Processes like "hardening," while spurned by most computer scientists as "filler" work, are actually complicated negotiations critical to the ultimate success or failure of innovation. I-school researchers can and do win grants to study these processes, and the studies can include iterative development of prototypes into production quality systems. I-school master's students are often well-qualified to oversee and execute this kind of iterative development. While I agree with all your points, I would add that funding agencies should favor funding collaborative work that includes not only CS iventors and domain-specific early adopters, but also the I-schools that have specifically positioned themselves to be able to play the bridging role often missing in such collaborations.