because of the opportunistic nature end-user programming [Brandt et al. 2008], people
who are engaging in end-user programming rarely have the time or interest in systematic
and disciplined software engineering activities. For example, Segal  reported on
several teams of scientists engaging in end-user programming, finding that software itself
is not valued, that the process of creating software was highly iterative and unpredictable,
and that testing was not considered important relative other domain-specific risks [Segal
2007]. These differences are coarsely summarized in Table 2, showing that end-user
software engineering can be characterized by its unplanned, implicit, opportunistic na-
ture, due primarily to the priorities and intents of the programmer (but perhaps also to
Given these differences, the challenge of end-user software engineering research is to
find ways to incorporate software engineering activities into users’ existing workflow,
without requiring people to substantially change the nature of their work or their priori-
ties. For example, rather than expecting spreadsheet users to incorporate a testing phase
into their programming efforts, tools can simplify the tracking of successful and failing
inputs incrementally, providing feedback about software quality as the user edits the
spreadsheet program. Approaches like these, and the ones reported throughout the rest of
this article, allow users to stay focused on their primary goals (teaching children, record-
ing a television, making scientific discoveries, etc.), while still achieving software qual-
It is important to note that we do not discuss the issue of educating users about soft-
ware engineering practices in this article. Many of the techniques discussed in our review
may have the side effect of teaching users about the importance of testing, for example,
but this is not the primary goal of these techniques. There is a case to be made that any-
one creating software with some potential for costly failure ought to engage in more rig-
orous and disciplined software engineering activities. This viewpoint and any research
associated with it, is outside the scope of this article.
3. END-USER SOFTWARE ENGINEERING RESEARCH
End-user software engineering research is interdisciplinary, drawing from computer sci-
ence, software engineering, human-computer interaction, education, psychology and
other disciplines. Therefore, there are several dimensions along which we could discuss
the literature in this area, including tools, language paradigm, research approach, and so
on. However, because we aim to contrast EUSE with professional software engineering,
we chose to organize the literature by software engineering activities commonly listed in
software engineering textbooks (e.g., [Ghezzi et al. 2002]). For each of these, however,
we frame the discussion from the perspective of an end user:
1. Requirements. How the software should behave in the world.
2. Design and specifications. How the software behaves internally to achieve the re-
3. Reuse. Using preexisting code to save time and avoid errors (including integration,
extension, and other perfective maintenance).
4. Testing and verification. Gaining confidence about correctness and identifying
5. Debugging. Repairing known failures by locating and correcting errors.
In our discussion of each of these, we will review research in understanding and sup-
porting these activities, and characterize the historical emphasis on particular paradigms
or end-user programming domains. In doing so, however, we do not imply that these ac-
tivities take place in sequence; indeed, the waterfall model [Ghezzi et al. 2002] is even
less appropriate in end-user programming than it is in professional development.
It is important to note that we do not explicitly discuss the implementation and use of
end-user programs, even though these activities are a central part of end-user program-
ming activity. Surveys of implementation issues in end-user programming have been dis-
cussed extensively in previous literature [Sutcliffe and Mehandjiev 2004, Kelleher and
Pausch 2005, Lieberman et al. 2006][Wulf et al. 2006]. The use of end-user programs
depends largely on for what purpose they were created and most end-user software engi-
neering research has attempted to be independent of purpose. We do, however, discuss
the maintenance of end-user programs in our discussion of sharing in Section 3.3.
3.1. What Should My Program Do? — Requirements
The term “requirements” refers to statements of how a program should behave in the
world (as opposed to the internal behavior of a program, which is how it achieves these
external concerns). For example, a requirement for a tax program might be “Create a
properly formatted 1040 tax form based on my financial data.” This is a statement of a
desired result, but not of how the result is achieved.
In considering the history of work on this activity, the contributions have largely fo-
cused on understanding the sources and types of requirements of different domains of
end-user programming and contrasting these with the role of requirements in professional
For example, in professional software engineering, projects usually involve a re-
quirements gathering phase that results in requirements specifications. These specifica-
tions can be helpful in anticipating project resource needs and for negotiating with cli-
ents. For end-user software engineering, however, the notion of requirements has to be
reinvented. Because their motivations are not related to the software, but to some other
goal, people engaging in end-user programming rarely have an interest in explicitly stat-
ing their requirements. This means they may be less likely to learn formal languages in
which to express requirements or to follow structured development methodologies. Fur-
thermore, in many cases, end users may not know the requirements at the outset of a pro-
ject; the requirements may only become clear in the process of implementation [Costabile
et al. 2006, Fischer and Giaccardi 2006, Mørch and Mehandjiev 2000, Segal 2007].
While this is also true in Agile development [Coplien and Harrison 2004], Agile develop-
ers explicitly recognize that requirements will evolve and have tools and processes that
plan for emergent requirements. In contrast, people engaging in end-user programming
are unlikely to plan in this way.
Another difference between requirements in professional and end-user software engi-
neering is the source of the requirements. In professional settings, the customers and us-
ers are usually different people from the developers themselves. In these situations, re-
quirements analysts use formal interviews and other methods [Beyer and Holtzblatt 1998]
to arrive at the requirements. End-user programmers, on the other hand, are usually pro-
gramming for themselves or for a friend or colleague. Therefore, end-user software engi-
neering is unlike other forms of software engineering, where the challenge of require-
ments definition is to understand the context, needs and priorities of other people and
organizations. For end users, requirements are both more easily understood (because the
requirements are their own) and more likely to change (because end users may need to
negotiate such changes only with themselves). Furthermore, end users’ requirements are
able to be implicit, and perhaps not even consciously recognized.
The situation in which an end user programs also affects the type of requirements. For
example, at an office, the requirements are often to automate repetitive operations (such
as transferring or transforming pieces of information such as customer names, products,
accounts, or documents). In this context, a decision to write a program at all corresponds
directly to real investment since time is money. End users who become successful at
automating their own work often find that their programs are passed on to others, whether
by simple sharing of tools between peers [MacLean et al. 1990], or as a means for man-
agers to define office procedures. These social contexts start to resemble the concerns of
professional software developers, for whom requirements analysis extends to the defini-
tion and negotiation of work practices [Ko et al. 2007].
At home, end-user software engineering is seldom about efficiency (except in the case
of office-like work that is done at home, such as taxes). Instead, typical tasks include
automation of future actions, such as starting a cooker or recording television. It is often
the case that one member of a household becomes expert in operating a particular appli-
ance, and assumes responsibility for programming it [Rode et al. 2005, Blackwell 2004].
In this context, requirements are negotiated within the social relations of the household,
in a manner that might have some resemblance to professional software experiences.
Sometimes there are no requirements to start with; for example, there is a long tradition
of “tinkering,” in which hobbyists explore ways to reconfigure and personalize technol-
ogy with no definite end in mind [Blackwell 2006]. Even though these hobbyists might
have envisioned some scenario of use when they made the purchase [Okada 2005], those
motivations may be abandoned later. Instead, requirements evolve through experimenta-
tion, seeing what one can do, and perhaps motivated by the possibility of exhibiting the
final product to others as a demonstration of skill and technical mastery.
In online contexts, end users must often consider the users of the web site or service
they are creating [Rode et al. 2006], demonstrating that the distinction between the intent
behind end-user programming and professional programming is a continuum rather than
a mutually exclusive categorization. Further, in some situations, requirements are shared
and negotiated, as happens with professional software developers. For example, Scaffidi
et al. interviewed six Hurricane Katrina site developers and found that three relied on
teammates for evaluating what features should be present and whether the site was viable
at all [Scaffidi et al. 2006]. In this same study, requirements were derived from beliefs
about the users of the program. One writer on the aggregators' email distribution list rec-
ognized that this “loosey goosey data entry strategy” would provide end users with
maximal flexibility. Unfortunately, the lack of validation led to semantic errors that soft-
ware propagated into the new database.
In educational contexts, programming is often used as a tool to educate students about
mathematics and science. What makes these classroom situations unique is how require-
ments are delivered to and adapted by students. For example, Rosson et al.  de-
scribe a participatory design workshop in which pairs of students and senior citizens cre-
ated simulation projects to promote discussion about community issues. In this situation,
requirements emerged from interpersonal communication in conversation and then were
later constrained by the capabilities of the simulation tool. This contrasts with a class-
room study of AgentSheets [Ioannidou et al. 2006], in which small groups of elementary
school students followed a carefully designed curriculum to design biological simula-
tions. In this situation, the instructions set the scope of the programming and students
chose the detailed requirements within this scope. In other contexts [Niess 2007], the
teachers and the students are end-user programmers. The degree to which the teachers
understood the abilities and limitations of spreadsheets affected not only the requirements
they developed in lab activities, but also the degree to which the students understood the
abilities and limitations of spreadsheets.
In general, research has not attempted to explicitly support requirements capture, and
the studies we have discussed should help reveal why. There are some techniques, how-
ever, that can be viewed as a form of requirements elicitation. For example, the Whyline
[Ko and Myers 2004], which allows users to ask “why” questions about their program’s
output, is an implicit way of learning about what behavior the user intended and did not
intend. The same is true of the goal debugging work in the spreadsheet paradigm [Abra-
ham and Erwig 2007b], which allows users to inquire about incorrect values in spread-
sheet output. Both of these systems are a form of requirements elicitation, in which the
requirements are used to support debugging.
3.2. How Should My Program Work? — Design and Design Specifications
In software engineering, design specifications specify the internal behavior of a system,
whereas the requirements are external (in the world). In professional software engineer-
ing, software designers translate the ideas in the requirements into design specifications.
These specifications can be helpful in coordinating implementation strategies and ensur-
ing the right prioritization of software qualities such as performance and reliability. De-
sign processes can ensure that all of the requirements have been accounted for.
In end-user programming, the challenge of translating one’s requirements into a
working program can be daunting. For example, interview studies of people who wanted
to develop web applications revealed that people are capable of envisioning simple inter-
active applications, but cannot imagine how to translate their requirements into working
applications [Rosson et al. 2005]. Further, in end-user software engineering, the benefits
of explicit design processes and specifications may be unclear to users. Most of the bene-
fits of being explicit come in the long term and at a large scale, whereas end users may
not expect long-term usage of their programs, even though this is not particularly accu-
rate. For example, studies of spreadsheets have shown that end users are creating more
and more complex spreadsheets [Shaw 2004], with typical corporate spreadsheets dou-
bling in size and formula content every three years [Whittaker 1999].
In general, research on incorporating specifications into end-user programming has
been quite pragmatic. If systems have supported any form of specifications, they have
been used (1) to support a particular kind of design process, such as prototyping or ex-
ploratory activities, (2) as the primary programming language, (3) or as an intermediate
language that either makes it easier to generate correct programs or helps with program
validation. Most of these technologies have focused on improving the creation and vali-
dation of spreadsheets, the prototyping of web sites, and the expression of preferences in
the privacy domain. There is considerably less work on model- and specification-based
approaches for interactive and web-based applications, though this is beginning to
change. In the rest of this section, we review these approaches in light of the various im-
balances and biases.
3.2.1. Design Processes. Software design processes constrain how requirements are
translated into design specifications and then implementations. They also involve a care-
ful consideration of tradeoffs among conflicting goals such as reliability, maintainability,
performance and other software qualities. These processes are usually learned by profes-
sionals through experience or training. Many end-user programmers, however, are “silent
designers” [Gorb and Dumas 1987], with no training in design and often seeing no bene-
fit to ensuring such qualities.
Some have proposed dealing with this lack of design experience by enforcing particu-
lar design processes. For example, Ronen et al. propose a design process that focuses on
ensuring that spreadsheets are reliable, auditable, and safe to update (without introducing
errors) [Ronen et al. 1989]. Powell and Baker define strategies and best practices for
spreadsheet design to improve the quality of created spreadsheets [Powell and Baker
2004]. Outside of the spreadsheet domain, Rosson et al. tested a design process with end-
user web programmers based on scenarios and concept maps, finding that the process was
useful for orienting participants towards particular design solutions [Rosson et al. 2007].
One problem with dictating proper design practices is that end-user programmers often
design alone, making it difficult to enforce such processes.
An alternative to enforcing good behavior is to let end users work in the way they are
used to working, but inject good design decisions into their existing practices. One cru-
cial difference between trained software engineers’ and end users’ approaches to problem
solving is the extent to which they can anticipate design constraints on a solution. Soft-
ware engineers can use their experience and knowledge of design patterns to predict con-
flicts and dependencies in their design decisions [Lakshminarayanan et al. 2006]. End-
user programmers, however, often come to understand the constraints on their programs’
implementations only in the process of writing their program [Fischer and Giaccardi
Because end-user programmers’ designs tend to be emergent, like their requirements,
requirements and design in end-user programming are rarely separate activities. This is
reflected in most design approaches that have been targeted at end-user programmers,
which largely aim to support evolutionary and exploratory prototyping, rather than up-
front design. For example, DENIM, a sketching system for designing web sites, allows
users to leave parts of the interface in a rough and ambiguous state [Newman et al. 2003].
This characteristic is called provisionality [Green et al. 2006], where elements of a design
can be partially, and perhaps imprecisely stated.
Another approach to dealing with end users’ emergent designs is to constrain what
can be designed to a particular domain. The WebSheets [Wolber et al. 2002] and Click
[Rode et al. 2005] environments both strive to aid users in developing web applications at
a level of abstraction that allows the environment to generate database-driven web appli-
cations, rather than write the necessary code at a lower level. There are several other
commercial systems that impose similar constraints on design within a certain domain.
Yahoo Pipes (http://pipes.yahoo.com), for example, allows the composition, selection and
refinement of RSS feeds, but limits these activities to a pre-defined set of operators. Ap-
ple’s Automator is a similar system, enabling the construction of dataflow programs that
process and operate on data with multiple applications, but limiting these operations to a
Supporting emergent designs under changing ideas of requirements can also be done
by supporting asynchronous or synchronous collaborations between professional software
developers and end-user programmers. Approaches that emphasize synchronous aspects
view professional developers and end-user programmers as a team (e.g., [Costabile et al.
2006, Fischer and Giaccardi 2006]). On the other hand, in strictly asynchronous ap-
proaches, the professional developer provides tailoring mechanisms for end-user pro-
grammers, thereby building in flexibility for end-user programmers to adjust the software
over time as new requirements emerge [Bandini and Simone 2006, Dittrich et al. 2006,
Figure 2. Links between web site content, sketched in DENIM, an informal web site sketching tool. Reprinted
from [Newman et al. 2003] with permission from authors.
Letondal 2006, Stevens et al. 2006, Won et al. 2006, Wulf et al. 2008]. As Pipek and
Kahler point out, tailorability is a rich area, including not only issues of how to support
low-level tailoring, but also numerous collaborative and social aspects [Pipek & Kahler
3.2.2. Writing Specifications. In professional software engineering, one way to ensure
that requirements have been satisfied is to write explicit design specifications and then
have tools check the program for inconsistencies with these specifications. In general,
tools and languages for expressing specifications tend to be declarative in nature, allow-
ing users to express what they want to happen, but not necessarily how.
In applying this idea to end-user software engineering, one approach is for a tool to
require up-front design. For example, ViTSL separates the modeling and data-entry as-
pects of spreadsheet development [Erwig et al. 2005]. The spreadsheet model is captured
as a template [Abraham et al. 2005] like the one in Figure 3. The ellipsis under row 3
indicates that the row can be repeated downwards; each row stores the scores of a student
enrolled in the course. These templates can then be imported into a system called Gencel
[Erwig et al. 2005, Erwig et al. 2006], which can be used to generate spreadsheets that are
guaranteed to conform to the model represented by the template. For example, an in-
stance of the template in Figure 3 is shown in Figure 4. The menu bar on the right allows
the user to perform insertion and deletion, protecting the user against unintended changes.
One limitation of this approach is that once a spreadsheet is generated from a template,
edits to the generated spreadsheet cannot be propagated back to the template. (This same
problem occurs in code generation systems in software engineering, where changes to the
code are not reflected back to the specifications.)
Some systems are intended to support the exploration of specifications by supporting
modeling for a particular type of application. For example, Berti et al.  describe
CTTE, a system that helps users convert natural language descriptions of tasks and sce-
narios into a hierarchy of subtasks. This is essentially a modeling language that helps
users to express the design and underlying workflow of a user interface. In a similar sys-
tem, Lin and Landay  describe Damask, a system that allows designers to proto-
type ubiquitous computing applications and test them with users. In both of these sys-
tems, the modeling languages were carefully designed with a particular domain and class
of applications in mind.
Most other systems that support specification writing are used for later verification
and checking, rather than generating programs. For example, Topes [Scaffidi et al. 2008]
allowing users to define string-based data types that can be used to check the validity of
data and operations in any programming language that stores information as strings.
Other researchers have developed end-user specification languages for privacy and secu-
rity. For example, Dougherty et al.  describe a framework for expressing access-
control policies in terms of domain concepts. These specifications are stated as “differ-
ences” rather than as absolutes. For example, rather than stating who gets privileges in a
declarative form, the system supports statements such as “after this change, students
should not gain any new privileges.” Cranor et al.  describe Privacy Bird, a related
approach, which includes a specification language for users to express their privacy pref-
erences in terms of the personal information being made accessible. Privacy Bird then
uses these specifications to warn users about web sites’ violations of these preferences.
Figure 3. A ViTSL template, specifying the underlying structure of a grading spreadsheet. The names appear in
rows and the assignments appear in columns, with the ellipses indicating repetition. Reproduced from [Abraham
and Erwig 2006c] with permission from authors.
Figure 4. An instance of the grade sheet template from Figure 3 loaded into Excel. The operations in the toolbar
on the right utilize the spreadsheet’s underlying structure to help users avoid introducing errors into the struc-
ture. Reproduced from [Abraham and Erwig 2006c] with permission from authors.
Documents you may be interested
Documents you may be interested