End-User Software Engineering and Why it Matters

End-User Software Engineering and Why it Matters

Margaret Burnett (Oregon State University, USA)
Copyright: © 2010 |Pages: 22
DOI: 10.4018/joeuc.2010101904
OnDemand PDF Download:
$37.50

Abstract

End-user programming has become ubiquitous; so much so that there are more end-user programmers today than there are professional programmers. End-user programming empowers—but to do what? Make bad decisions based on bad programs? Enter software engineering’s focus on quality. Considering software quality is necessary, because there is ample evidence that the programs end users create are filled with expensive errors. In this paper, we consider what happens when we add considerations of software quality to end-user programming environments, going beyond the “create a program” aspect of end-user programming. We describe a philosophy of software engineering for end users, and then survey several projects in this area. A basic premise is that end-user software engineering can only succeed to the extent that it respects that the user probably has little expertise or even interest in software engineering.
Article Preview

End-User Development (Eud)

Familiarity with software applications has become an essential requirement for professionals in a variety of complex domains: architects, doctors, engineers, biochemists, statisticians, and film directors (among many others) all depend on the mastery of various collections of applications (Eisenberg & Fischer, 1994) in their areas of expertise. These applications, to be at all useful, must provide domain professionals with complex and powerful functionality. However, in doing so, these systems likewise increase the cognitive cost of mastering the new capabilities and resources that they offer. Moreover, the users of these applications will notice that “software is not soft”—that is, that the behavior of a given application cannot be changed or meaningfully extended without substantial reprogramming effort.

The need for end-user development is not a luxury but a necessity: computational systems modeling some particular “world” are never complete; they must evolve over time because (1) the world changes and new requirements emerge; and (2) skilled domain professionals change their work practices over time—their understanding and use of a system will be very different after a month and certainly after several years. If systems cannot be modified to support new practices, users will be locked into existing patterns of use.

These problems were recognized early in the context of expert systems and domain-oriented environments as illustrated by the following two examples:

  • Expert systems: The Teiresias system (Davis, 1984) was a module to support domain professionals to augment the existing knowledge base of a medical expert system; the objective of this component was to establish and support interaction at a discourse level that would allow domain professionals to articulate their knowledge without having to program in Lisp.

  • Domain-oriented environments: The Janus-Modifier system (Fischer & Girgensohn, 1990; Girgensohn, 1992) supported not just human-computer interaction but human problem-domain interaction to allow kitchen designers to introduce new components and new critiquing rules into design environments in support of kitchen design.

Complete Article List

Search this Journal:
Reset
Open Access Articles: Forthcoming
Volume 29: 4 Issues (2017)
Volume 28: 4 Issues (2016)
Volume 27: 4 Issues (2015)
Volume 26: 4 Issues (2014)
Volume 25: 4 Issues (2013)
Volume 24: 4 Issues (2012)
Volume 23: 4 Issues (2011)
Volume 22: 4 Issues (2010)
Volume 21: 4 Issues (2009)
Volume 20: 4 Issues (2008)
Volume 19: 4 Issues (2007)
Volume 18: 4 Issues (2006)
Volume 17: 4 Issues (2005)
Volume 16: 4 Issues (2004)
Volume 15: 4 Issues (2003)
Volume 14: 4 Issues (2002)
Volume 13: 4 Issues (2001)
Volume 12: 4 Issues (2000)
Volume 11: 4 Issues (1999)
Volume 10: 4 Issues (1998)
Volume 9: 4 Issues (1997)
Volume 8: 4 Issues (1996)
Volume 7: 4 Issues (1995)
Volume 6: 4 Issues (1994)
Volume 5: 4 Issues (1993)
Volume 4: 4 Issues (1992)
Volume 3: 4 Issues (1991)
Volume 2: 4 Issues (1990)
Volume 1: 3 Issues (1989)
View Complete Journal Contents Listing