This can be a dishonest game of gotcha by the critics, but the gap is often a rewarding place to concentrate our efforts (in fact, much of teaching, administrating and fossil-hunting actually consists of looking for gaps and filling them).
One recurring gap is in special apps programming, which falls between the information technology and computer science domains. Many colleges have solid IT, so they have about the amount of hardware they should, as current and secure as they can manage and afford, and it mostly does what they need computers, software and networks to do. On the same campus, the CS department is training the tech developers and creators for the next generation.
But what about getting present-day tech to solve present-day problems? That's the domain of special apps, and just as the hardest part in communication networks is the last mile, the biggest gap in IT deployment is the trip across the desk from the field tech to the end user.
[ A MOOC of your own? Read EdX Goes Open Source To Woo MOOC Developers.]
Special apps might be needed anywhere:
-- A historian has found an archived file of raw data in an obsolete medium, apparently studied once in 1982 and not since, that, analyzed with modern tools, might shed light on the 1980 elections.
-- A student services counselor is stuck with record keeping that doesn't clearly mark whether or not a student with a problem wants to be re-contacted or in what way, so students in difficulty are perpetually annoyed, neglected or both.
-- An English professor is just wondering about how to download Google Ngrams in a format where she can mark them up, then convert them to a required format for a conference presentation.
-- A dean needs to route student achievement reports to hometown newspapers, and needs to link their circulation areas to home address, high school and county.
It would be senseless for any of them to neglect their own work to acquire IT skills they will probably need only once. Yet they can't just hand it off, either, because all of them have specialized knowledge that must be part of the process:
-- Now-obsolete coding conventions from the polling systems of decades ago.
-- Complex federal, state, system and college rules about privacy.
-- Which squiggle on the graph is most interesting to specific colleagues.
-- Which regional media overlap and where.
The gap between operational support of existing tools and original development thus translates into a gap between what all of them could achieve with better control of their own IT tools and what all of them must settle for if they want to use IT in the conventional way.
Metaphorically, IT can sell you a plane ticket to Chicago, and CS can build you a moon rocket, but what if you want to go to Montevideo and back, just this once? It's obviously possible but who's going to get you there, assuming you don't want to learn to fly a plane (let alone build one)?
On many campuses, there's an answer, some of the time: under one name or another, they create a mostly undergrad team that is on call for jobs like this. Sometimes the students on the team are working for work-study or for grade credit, but college special-apps teams all seem to have the same lifecycle: a big initial announcement, a long period of hardly anyone seeming to know they're there, a few faculty and administrators help, a large number who are frustrated, a sustained fizzle, and the shutdown or mothballing of the program until it emerges again.
Why is that so often the pattern? I'd argue it's because there is yet another gap to close, and closing it might be one of the best things IT and CS can do together. The missing element is specification and documentation. The special apps programming team tends to be made up of bright people who are perhaps a little too impressed with what they think they already know, and an energetic can-do attitude, which is great for atmosphere but not so conducive to listening.
If that sounds familiar, it's because it's the story of special applications programming in industry since the dawn of time. And the industrial solution will work on campus, too: Every team needs a specs-and-docs member, who ideally is also on the testing/QA part of the team. (And if the team doesn't have that, we've just found another gap. They're everywhere!) If it's a student worker, you want someone who has at least had tech writing, but it will be better if they've had courses in specification writing or applications-oriented systems analysis. The faculty or grad student adviser may even want to work on some standardized reporting systems, which could make a nice senior or first-year-grad project in document systems design.
Clarifying communication, and making it accountable and testable, gives the student coding team a much more real-world-like work experience, and makes it far more likely they'll deliver something useful. The team wins, the users win and people go home happy.
And as a bonus, the spec-and-doc member is getting a great resume line, which just might help in closing that gap between successful student and employed professional.
I'll freely admit that on eight campuses, I've only seen special apps teams struggling and flailing, but there must be some out there that have succeeded. And I've never seen one that did anything other than send a proficient student programmer over to say, "So what do you need?"
Surely someone has a more positive experience to share. Why do you think they did better than what I'm describing? (Extra points awarded if they had a real spec-and-doc system in place!)