There are of course setbacks and challenges to implementing interdisciplinary computing and our group discussed those as well (if you haven't read the previous two posts, this is the third in the thread). As we had people with backgrounds past and present in biology, computer science, math, physics, music - performance and theory, architecture (not the computer kind), healthcare, there were lots of angles.
In our first morning discussion of these challenges, some themes popped out, just as they had with our discussion of positive experiences. Here is some of what arose for consideration:
Lack of common vocabulary. Specialties have their own lingo, buzzwords, abbreviations, and sometimes the words are the same words used by another field but with different meanings. Engaging in conversation with a specialist in another field can be an instant reminder about how much we have internalized and take for granted when we talk among ourselves.
Different perspectives on appropriate methodologies for research, assessment, reporting, project development. This is a huge topic. Simple to explain and discuss (but not necessarily resolve): is first person or third person expected in a formal write up? Not at all simple to resolve: is statistical or qualitative research desired or valid...what type of statistical or qualitative...how is rigor agreed upon? Really difficult: what does the other field actually *do* when they design and implement a program or project and can it be (should it be) fully understood by the participant from another discipline who works on the project?
Application level skill issues. This point follows up on the last point in the previous paragraph. One example: Discipline X wants to use software A; Discipline Y wants to use software B. Both have their well supported reasons. How to resolve the question to everyone's satisfaction? Similarly, programming and programming language issues can be "exhausting" as one person put it so well. What to use, how many to use, does it have to be a specific language? You know, we have these conversations even within computing; we exhaust ourselves talking about languages. When interdisciplinary teams tackle the language questions the discussion increases in complexity several orders of magnitude.
Trust. This is perhaps one of the biggies. Perhaps the biggest. People related experiences about the need to build trust between disciplines, between people at different levels of an organization, between people with different responsibilities.
Even when there is abundant goodwill on all sides trust has to be earned. It cannot be taken for granted or else some innocent blunder may set back or seriously damage a project. Sometimes, there are large silos that people work in and these have to be bridged. Note: lots of words were used, and I'm not sure which I prefer - bridging seems to convey the positive intentions of everyone in the meeting.
What is computing and/or computer science anyway? This is another topic where even within our own computing discipline(s) we do not always agree. Exhausting. Another exhausting topic. Members of our meeting related experiences about perceptions and mis-perceptions of what "it" is, and in particular how the word "technology" fits in. Similar stories have appeared on the SIGCSE list and many other forums.
I'm intentionally not repeating specific examples of the setbacks we discussed because I don't want to unintentionally embarrass anyone nor imo is it relevant for this post that is trying (with questionable success) to stay manageable in length. I want to focus on the high level issues.
A few summative related issues that lead to setbacks for interdisciplinary initiatives: the tension b/w tools and theory; specialists vs. generalists vs. interdisciplinarians (blogger thinks that is not a word... how timely!); pure vs. applied; student majors vs. student non-majors. And the notable point that silos can occur within a department - not just between departments.
Challenges that were phrased as questions included:
How to help people in a partner discipline continue to use mutually agreed upon / developed concepts as their students move up within their curriculum? Problematic.
How to keep an interdisciplinary course from turning "light and fluffy" or just an exercise in tool use? If students don't have a quantitative background for example, how do you give them that background sufficiently to proceed with the course? Just adding a prerequisite or two or three doesn't address the problem head on.
Computer science as a discipline has our set of "big ideas". We can abstract them, but how do we then help other people to understand and want to work with them? (this harks back to the vocabulary, method and perspective challenges)
And to end on a LARGE note: there are a whole set of different challenges for the interdisciplinary team that is starting a program from the ground up vs. the team that is working within existing programs and major fields of study. Even more so when the collaborators consist of computer scientists and experts from the non sciences.
phew! Much of the above will not be news if you have been involved in interdisciplinary efforts. However! that is one reason why I chose to start the conversation several posts ago with the upbeat and positive side of this work. No problem is impossible to address in one way or another. But to do so we had to first lay them out and lay them out we did!
No comments:
Post a Comment