End-user software engineering does not mimic the traditional approaches of segregated support for each element of the software engineering life cycle, nor does it ask the user to think in those terms. Instead, it employs a feedback loop sup-ported by behind-the-scenes reasoning, with which the system and user collaborate to monitor dependability as the end user's program evolves. This approach helps guard against the introduction of faults 1 in the user's program and if faults have already been introduced, helps the user detect and locate them. Because spreadsheet languages are the most widely used end-user programming languages to date-in fact, they may be the most widely used of all programming languages-we have prototyped COMMUNICATIONS OF THE ACM September 2004/Vol. 47, No. 9 53A strategy that allows end users the ability to perform quality control methods as well as inspires them to enhance the dependability of their software themselves.End-user programming has become the most common form of programming in use today [2], but there has been little investigation into the dependability of the programs end users create. This is problematic because the dependability of these programs can be very important; in some cases, errors in end-user programs, such as formula errors in spreadsheets, have cost millions of dollars. (For example, see www.theregister.co.uk/content/67/31298.html or panko.cba.hawaii.edu/ssr/Mypapers/whatknow.htm.) We have been investigating ways to address this problem by developing a software engineering paradigm viable for end-user programming, an approach we call end-user software engineering. 1 We follow the standard terminology for discussing program errors. A "failure" is an incorrect output, and a "fault" is the incorrect element(s) of source code causing the failure. For example, an answer of "D" in a spreadsheet cell if the student's grade should actually be a "B" is a failure; the incorrect formula, such as omission of one of the student's test grades in the sum upon which his/her letter grade is based, is the fault.

No abstract

No abstract

Despite their ability to help with program correctness, assertions have been notoriously unpopular-even with professional programmers. End-user programmers seem even less likely to appreciate the value of assertions; yet end-user programs suffer from serious correctness problems that assertions could help detect. This leads to the following question: can end users be enticed to enter assertions? To investigate this question, we have devised a curiosity-centered approach to eliciting assertions from end users, built on a surprise-explain-reward strategy. Our follow-up work with end-user participants shows that the approach is effective in encouraging end users to enter assertions that help them find errors.

No abstract