Government // Leadership
Commentary
6/13/2013
02:58 PM
John Barnes
John Barnes
Commentary
Connect Directly
Twitter
RSS
E-Mail
50%
50%

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

Previous
1 of 2
Next
Comment  | 
Print  | 
More Insights
Comments
Oldest First  |  Newest First  |  Threaded View
David F. Carr
50%
50%
David F. Carr,
User Rank: Author
6/18/2013 | 8:12:28 PM
re: How To Close Gaps In Campus Apps
Are you thinking of these apps as being semi-disposable, created to meet the needs of one specific research project? Or do they need to be architected to be maintainable code over the long term?
Some Other John Barnes
50%
50%
Some Other John Barnes,
User Rank: Apprentice
6/18/2013 | 9:37:59 PM
re: How To Close Gaps In Campus Apps
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.
David F. Carr
50%
50%
David F. Carr,
User Rank: Author
7/2/2013 | 6:26:48 PM
re: How To Close Gaps In Campus Apps
Here's another approach for addressing simple data tracking apps.

University Of San Francisco Stretches Uses Of ServiceNow Apps @servicenow #highered http://twb.io/14N7Ayn
2014 US Salary Survey: 10 Stats
2014 US Salary Survey: 10 Stats
InformationWeek surveyed 11,662 IT pros across 30 industries about their pay, benefits, job satisfaction, outsourcing, and more. Some of the results will surprise you.
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Must Reads Oct. 21, 2014
InformationWeek's new Must Reads is a compendium of our best recent coverage of digital strategy. Learn why you should learn to embrace DevOps, how to avoid roadblocks for digital projects, what the five steps to API management are, and more.
Video
Slideshows
Twitter Feed
InformationWeek Radio
Archived InformationWeek Radio
A roundup of the top stories and community news at InformationWeek.com.
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.