Earlier research on gender effects with software features intended to help problem-solvers in end-user debugging environments has shown that females are less likely to use unfamiliar software features. This poses a serious problem because these features may be key to helping them with debugging problems. Contrasting this with research documenting males' inclination for tinkering in unfamiliar environments, the question arises as to whether encouraging tinkering with new features would help females overcome the factors, such as low self-efficacy, that led to the earlier results. In this paper, we present an experiment with males and females in an end-user debugging setting, and investigate how tinkering behavior impacts several measures of their debugging success. Our results show that the factors of tinkering, reflection, and self-efficacy, can combine in multiple ways to impact debugging effectiveness differently for males than for females.

We have been working to uncover gender differences in the ways males and females problem solve in end-user programming situations, and have discovered differences in males' versus females' use of several debugging features. Still, because this line of investigation is new, knowing exactly what to look for is difficult and important information could escape our notice. We therefore decided to bring data mining techniques to bear on our data, with two aims: primarily, to expand what is known about how males versus females make use of end-user debugging features, and secondarily, to find out whether data mining could bring new understanding to this research, given that we had already studied the data manually using qualitative and quantitative methods. The results suggested several new hypotheses in how males versus females go about end-user debugging tasks, the factors that play into their choices, and how their choices are associated with success

Spreadsheet languages, which include commercial spreadsheets and various research systems, have had a substantial impact on end-user computing. Research shows, however, that spreadsheets often contain faults. Thus, in previous work we presented a methodology that helps spreadsheet users test their spreadsheet formulas. Our empirical studies have shown that end users can use this methodology to test spreadsheets more adequately and efficiently; however, the process of generating test cases can still present a significant impediment. To address this problem, we have been investigating how to incorporate automated test case generation into our testing methodology in ways that support incremental testing and provide immediate visual feedback. We have used two techniques for generating test cases, one involving random selection and one involving a goal-oriented approach. We describe these techniques and their integration into our testing environment, and report results of an experiment examining their effectiveness and efficiency.

Although gender differences in a technological world are receiving significant research attention, much of the research and practice has aimed at how society and education can impact the successes and retention of female computer science professionals-but the possibility of gender issues within software has received almost no attention. If gender issues exist with some types of software features, it is possible that accommodating them by changing these features can increase effectiveness, but only if we know what these issues are. In this paper, we empirically investigate gender differences for end users in the context of debugging spreadsheets. Our results uncover significant gender differences in self-efficacy and feature acceptance, with females exhibiting lower self-efficacy and lower feature acceptance. The results also show that these differences can significantly reduce females' effectiveness.

Previous research has revealed gender differences that impact females' willingness to adopt software features in end users' programming environments. Since these features have separately been shown to help end users problem solve, it is important to female end users' productivity that we find ways to make these features more acceptable to females. In this paper, we draw from our ongoing work with users to help inform our design of theory-based methods for encouraging effective feature usage by both genders. This design effort is the first to begin addressing the gender differences in the ways that people go about problem solving in end-user programming situations.

End-user programmers, because they are human, make mistakes. However, past research has not considered how visual end-user debugging devices could be designed to ameliorate the effects of mistakes. This paper empirically examines oracle mistakes - mistakes users make about which values are right and which are wrong - to reveal differences in how different types of oracle mistakes impact the quality of visual feedback about bugs. We then consider the implications of these empirical results for designers of end-user software engineering environments.

Although researchers have begun to explicitly support end-user programmers' debugging by providing information to help them find bugs, there is little research addressing the proper mechanism to alert the user to this information. The choice of alerting mechanism can be important, because as previous research has shown, different interruption styles have different potential advantages and disadvantages. To explore impacts of interruptions in the end-user debugging domain, this paper describes an empirical comparison of two interruption styles that have been used to alert end-user programmers to debugging information. Our results show that negotiated-style interruptions were superior to immediate-style interruptions in several issues of importance to end-user debugging, and further suggest that a reason for this superiority may be that immediate-style interruptions encourage different debugging strategies.

Emerging research has sought to bring effective debugging devices to end-user programmers. This research has largely focused on how well such devices bring genuine "functional" rewards to end users. However, emerging models of programming behavior indicate that another, often ignored, type of reward-perceivable rewards-can play an equally vital role in how well debugging devices serve end users. Using an empirically evaluated fault localization device, this paper investigates the impact such perceivable rewards can have on end-user debugging. Our results indicate that perceivable rewards alone can significantly improve the effectiveness and understanding of end users performing debugging tasks.

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.

There has been little research on end-user program development beyond the activity of programming. Devising ways to address additional activities related to end-user program development may be critical, however, because research shows that a large proportion of the programs written by end users contain faults. Toward this end, we have been working on ways to provide formal "software engineering" methodologies to end-user programmers. This paper describes an approach we have developed for supporting assertions in end-user software, focusing on the spreadsheet paradigm. We also report the results of a controlled experiment, with 59 end-user subjects, to investigate the usefulness of this approach. Our results show that the end users were able to use the assertions to reason about their spreadsheets, and that doing so was tied to both greater correctness and greater efficiency.

Spreadsheet languages, which include commercial spreadsheets and various research systems, have had a substantial impact on end-user computing. Research shows, however, that spreadsheets often contain faults. Thus, in previous work, we presented a methodology that assists spreadsheet users in testing their spreadsheet formulas. Our empirical studies have shown that this methodology can help end-users test spreadsheets more adequately and efficiently; however, the process of generating test cases can still represent a significant impediment. To address this problem, we have been investigating how to automate test case generation for spreadsheets in ways that support incremental testing and provide immediate visual feedback. We have utilized two techniques for generating test cases, one involving random selection and one involving a goal-oriented approach. We describe these techniques, and report results of an experiment examining their relative costs and benefits.

Spreadsheets are among the most common form of software in use today. Unlike more traditional forms of software however, spreadsheets are created and maintained by end users with little or no programming experience. As a result, a high percentage of these "programs" contain errors. Unfortunately, software engineering research has for the most part ignored this problem. We have developed a methodology that is designed to aid end users in developing, testing, and maintaining spreadsheets. The methodology communicates testing information and information about the impact of cell changes to users in a manner that does not require an understanding of formal testing theory or the behind the scenes mechanisms. The paper presents the results of an empirical study that shows that, during maintenance, end users using our methodology were more accurate in making changes and did a significantly better job of validating their spreadsheets than end users without the methodology.

Is it possible to achieve some of the benefits of formal testing within the informal programming conventions of the spreadsheet paradigm? We have been working on an approach that attempts to do so via the development of a testing methodology for this paradigm. Our “What You See Is What You Test” (WYSIWYT) methodology supplements the convention by which spreadsheets provide automatic immediate visual feedback about values by providing automatic immediate visual feedback about “testedness”. In previous work we described this methodology; in this paper, we present empirical data about the methodology's effectiveness. Our results show that the use of the methodology was associated with significant improvement in testing effectiveness and efficiency even with no training on the theory of testing or test adequacy that the model implements. These results may be due at least in part to the fact that use of the methodology was associated with a significant reduction in overconfidence.

Continuous visual feedback is becoming a common feature in direct-manipulation programming systems of all klndsfrom demonstrational macro builders to spreadsheet packages to visual programming languages featuring direct manipulation.But does continuous visual feedback actually help in the domain of programming?There has been little investigation of this question, and what evidence there is from related domains points in conflicting directions.To advance what is known about this issue, we conducted an empirical study to determine whether the inclusion of continuous visual feedback into a direct-manipulation programming system helps with one particular task: debugging.Our results were that although continuous visual feedback did not significantly help with debugging in general, it did significantly help with debugging in some circumstances.Our results also indicate three factors that may help determine those circumstances.

article CS0: computer science orientation course Share on Author: Curtis R. Cook Computer Science Department, Oregon State University, Corvallis, OR Computer Science Department, Oregon State University, Corvallis, ORView Profile Authors Info & Claims ACM SIGCSE BulletinVolume 29Issue 1March 1997 pp 87–91https://doi.org/10.1145/268085.268119Published:01 March 1997 10citation494DownloadsMetricsTotal Citations10Total Downloads494Last 12 Months14Last 6 weeks1 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteGet Access

Parallel computing has been portrayed as a technology that will enable users to solve very large and complex problems very quickly. But has this portrayal created unreasonably high expectations for potential parallel users? This paper reports the results of a survey designed to delineate the differences in how computer scientists and technical programmers approach parallel programming. Responses from 326 "potential parallel programmers" at Supercomputing '93 are presented. The analysis provides information about the costs and benefits associated with parallel programming, application development activities, and the extent of tool use in those activities. It shows that users expect very dramatic gains in performance from parallel machines, while underestimating the amount of effort that will be needed. The results should be of interest to parallel tool developers and people involved in training parallel programmers.>

The ability to comprehend a program written by other individuals is becoming increasingly important in software development and maintenance. In an attempt to encourage undergraduate Computer Science students to write informative and usable documentation, the literate programming paradigm was incorporated into the teaching of one undergraduate Computer Science course at Augustana College. This paper describes the concept of literate programming, the experience of using literate programming to teach good programming practices, and the results from the experiment that showed that literate programming encourages more documentation.

The authors develop a model of software maintenance based upon an objective decision rule which determines whether a given software module can be effectively modified or whether it should instead be rewritten. Completely rewriting a module can be expensive, but it can be even more expensive if the module's structure has been severely degraded over successive maintenance activities. A module that is likely to experience significant maintenance activity is called change prone. The authors suggest that early identification of change-prone modules through the use of change measures across release cycles can be an effective technique in allocating maintenance resources.>

This paper describes a two term junior level Applications Programming course. The goal of the course is to provide the guidance and tools a student needs in order to write medium to large sized programs and to provide the experience of working on a “real world” project. Topics covered during the first term are documentation, magnetic tapes, program design, testing, debugging and programming style. The second term consists entirely of student teams doing “real world” projects applying the concepts from the first team.

This paper describes a self-paced audio-tutorial introductory Fortran programming course. The course is designed for students with no previous programming experience and consists of nine lessons. Each lesson has two parts: (1) a handout that directs the student's reading in the course text and contains comments, suggestions, examples and self-test quizzes; (2) a handout and accompanying cassette tape that solves example problems in detail - problem analysis, development of algorithm (flowchart) and program. There are six programming assignments and a test on each lesson. A unique feature of the lessons is the use of peek-a-boo strips to aid and encourage students to carefully read the example programs and to show the structural relation between the flowchart and the program.

In this paper we consider first order context-free, linear, and regular graph grammars and obtain many results similar to those for the corresponding string grammars. We obtain normal forms for context-free and regular graph grammars, simplification lemmas, and algorithms for membership, emptiness, finiteness and infiniteness. We show the relation between regular graph languages and regular sets and show that the set of graphs resembling the nonregular set $\{ a^n b^n | n \geqq 1\} $ is not generated by a first order context-free graph grammar. We also give several graphical characterizations of each of the three types of graph grammars.