How To Close Gaps In Campus Apps

To close the programming applications gap on campus, you often must close several other gaps first.

Inside Eight Game-changing MOOCs

(click image for larger view and for slideshow)

Education, administration and evolutionary biology all are subject to the perpetual gap problem: Whenever you get a handle on one place in the continuum, people instantly complain that you don't have anything on either side of your new handle. Every time you fill a gap, you split it into two (though smaller) gaps.

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 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:

-- 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.

David, I think the answer to that one, as with so many "or" questions, is "Yes." Some apps are going to be natural one-time one-use and throw it away; some will be "fix it once and it lasts forever;" and some will probably exhibit that horrible mission creep in which what started out as a simple mailing list program grows to rule the universe. But in any of those cases, documenting and specifying, and putting someone in charge of it, will reduce headaches down the road, whether it's because five years from now the guy who needed just this one thing once is writing a book that incorporates it and needs to remember what it was, or because it has created a de facto data standard that years later it becomes vital to understand, or because there will eventually be a Version 17.3.A of the system. My real position boils down to, there are going to be such apps, written by somebody. Better to have them written by people who get credit and experience --and if so, even better to have them have the experience of getting it right, and getting it right means documented.