The quote below is from:
Hunt, Leta, Marilyn Lundberg, and Bruce Zuckerman. “Getting beyond the common denominator” Literary and Linguistic Computing(2011) 26 (2): 217-231. <http://llc.oxfordjournals.
org/content/26/2/217.full>.
I continue to use this quote as it is extremely useful in explaining differences with enterprise computing (desktop to payroll systems) from highly experimental work and these from “application engineering” which is research-intensive, experimental, and has to work and function well with “application engineering” being the type of work done for the UF Digital Collections, the Digital Library of the Caribbean (dLOC), and the SobekCM Open Source Software.
the overriding goal of research engineers—who typically operate within an academic environment (e.g. in disciplines/programs/
departments such as computational sciences, distributed scalable systems, intelligent systems, compression, etc.)—is to make quantum leaps forward in their own fields rather than to simply facilitate advances in ancient studies. Of course, the goals of HASS scholars and research engineers can and do coincide. […]
In contrast, application engineers (e.g. database engineers,application architects, programmers, systems analysts, etc.) define ‘success’ in terms of a working application that satisfies specified user needs, in our case the needs of the scholars of ancient studies. Typically, experienced, successful application engineers rely on proven technologies, rather than on speculative and untried technologies in order to address creatively the specific needs of the users who employ them. They also must address pragmatic issues such as reliability, maintainability, and changing user needs over time.
It is important to distinguish application development from the work of Information Technology (IT) departments of academic institutions. Although their specific role varies from place to place, IT departments are typically responsible for making sure that the computer information systems necessary to keep things running smoothly continue to function as expected. In this context, small applications (a limited script here, a small program there) may be developed and maintained by IT departments. Still, the IT engineers must maintain their focus on the particular computer systems of the university infrastructure, and the applications necessary for their maintenance are their primary responsibility. It is not the role of IT departmental engineers to keep up with and/or develop emerging technologies; nor should they be concerned—let alone distracted—by the problems inherent in new application development techniques unrelated to their work. Indeed, it is not cost-effective to divert IT engineers from their work in order to become involved with the development of a new application. Invariably, a more substantial number of engineers are required to develop new, complex applications than are required simply for maintenance. Thus, if twenty engineers are required to develop a particular application and only two or three to monitor and maintain it, then it would hardly make sense, in terms of cost-effectiveness, to hire and keep on staff all twenty new engineers as employees for the foreseeable future. Rather, an institution might initially contract, temporarily, the twenty people for the development of the application and then keep or hire the two or three required to maintain the application thereafter. Alternatively, an institution might contract with a software development company, experienced in the development of a particular application. This company may also maintain the application or might train in-house engineers for the subsequent maintenance of the application. There are exceptions to this, especially in very large organizations (for example, Microsoft, Oracle, IBM), which maintain large numbers of application engineers as personnel. But the point is this: IT work is not to be confused with application engineering. […] Clearly, IT engineers must be consulted should a given application require integration into the academic cyberinfrastructure, but their limited and valuable time should not be spent on the all-consuming work of architecting, engineering, and implementing a new, complex application for which there will be a substantial learning curve.