About a decade ago, I was in the midst of completing my degree in information science at the University of Michigan. Wanting to avoid just taking a bunch of vanilla courses, such as computer programming, data modeling, and cognitive psychology, (which all are valuable and important courses to take), I sought out courses in other schools and departments to broaden my horizons. One such course, in the School of Art & Architecture, was a physical computing course called “Interfacing.”
In the Interfacing course, an art student would pair up with a student from the School of Electrical Engineering to collaborate in building a series of electronic interactive art pieces. Since I had registered for the course via the School of Art, I was considered the “artist” and was paired up with an engineering student. Together, we developed our project idea, an analog radio that would tune itself based on proximity sensors, allowing people passing by to discover that their movement was affecting the radio frequency. Then, we created a circuit board from scratch, soldered on all the necessary electronics, and programmed a 10K chip with the logic needed to have input from the proximity sensor to drive a motor attached to the tuning wheel of the radio.
While we only had mixed success with our nifty little human proximity tuner, the most important lesson was that of working across and truly integrating two disciplines, in this case art and engineering, and discovering that what the other does is not as mysterious and weird as one might think. I didn’t know it at the time, but this was my first foray into Pairing, a concept currently receiving widespread and well-deserved attention thanks to the Agile movement. Pairing is most well-know in the form of Pair Programming, in which two developers share one keyboard, one “driving” (i.e. typing), the other “navigating” (i.e. telling the other programmer what to type.) To an outsider, this may seem a strange ritual indeed, but it is in fact a powerful way of generating a highly focused whole-brain work session, in which one person is continually debugging the work of the other. (I.e. as the driver types, they are also thinking about and evaluating everything the navigator tells them to type, able to continually make course-corrections.)
In our case, we were pairing across disciplines, which can be just as powerful. It becomes an act of debugging or evaluating the work of the other across dimensions. While the engineer may be deep in their C programming mode, I am thinking about how the resulting code will impact the experience of people walking in front of the tuner. While the engineer is gaining a deeper awareness of the impact of their coding choices on the people interacting with the machine, I as the “artist” am gaining a deeper appreciation for the complexities of software development (for example, when programming a chip, you can’t call a library function such as “abs()” to get an absolute value, you have to actually write an algorithm for that from scratch.)
Unfortunately, this type of cross-disciplinary pairing is, as far as I know, incredibly rare in academia. Instead, artists or designers are often housed separately and away from engineers and computer scientists, rarely if ever having any contact with one another. The same seems to hold true for those in the interaction and graphic design fields. Until my first day on my first job out of school as an Information Architect at a small web agency, I had never worked with a graphic designer. I have to wonder how many of those students currently studying interaction design are spending time working side-by-side with software developers. Based on my informal survey, the amount of time they spend together in academia is approximately zilch.
It is no wonder, then, that so many people in the interaction design community I have spoken with seem to think of developers as the Other, as people who simply are different from Us, who simply do not understand the subtleties and nuances of designing a user experience, who do not think the same way that We do. It is no wonder that so many people in the interaction design community suffer from what I call The Genius Problem, in which they see themselves as the creators of ideas, while developers are mere builders, construction workers who transform these ideas into reality. It is no wonder that so many people in the interaction design community greet the idea of Agile software development with a high degree of suspicion. It is no wonder because that is a mindset that academic institutions (unwittingly) have indoctrinated them into during the formative years of their practice.
As long as academic institutions in general, and interaction design programs specifically, do not begin to truly integrate their students with those in the computer science departments, this problem will persist. Agile should not be something that is only taught in computer science departments, and only discovered by interaction designers on their first day at work. For Agile to be effective, these students need come into these roles with an understanding of what they do as not being something separate from what software developers do. And for that to happen, computer programming students should be spending time with graphic design students, graphic design students should be spending time with interaction design students, interaction design students should be spending time with computer science students, and so forth. Until that happens, the integration of Agile with other disciplines will continue to be a perpetual struggle.