Claims for the virtues of visual programming languages have generally been strong, simple-minded statements that visual programs are inherently better than textual ones. They have paid scant attention to previous empirical literature showing difficulties in comprehending visual programs. This paper reports comparisons between the comprehensibility of textual and visual programs, drawing on the methods developed by Green (1977) for comparing detailed comprehensibility of conditional structures. The visual language studied was LabView, a circuit-diagram-like language which can express conditionals either as `forwards' structures (condition implies action, with nesting) or as `backwards' structures (action is governed by conditions, with boolean operators in place of nesting). Green (1977) found that forwards structures gave relatively better access to `sequential' information, and Gilmore and Green (1984) showed `backwards' structures gave relatively better access to `circumstantial' inf...

Abstract not found

The eXtreme Programming (XP) software development methodology has received considerable attention in recent years. The adherents of XP anecdotally extol its benefits, particularly as a method that is highly responsive to changing customer's desires. While XP has acquired numerous vocal advocates, the interactions and dependencies between XP practices have not been adequately studied. Good software engineering practice requires expertise in a complex set of activities that involve the intellectual skills of planning, designing, evaluating, and revising. We explore the practices of XP in the context of software engineering education. To do so, we must examine the practices of XP as they influence the acquisition of software engineering skills. The practices of XP, in combination or isolation, may provide critical features to aid or hinder the development of increasingly capable practitioners. This paper evaluates the practices of XP in the context of acquiring these necessary Software Engineering skills.

Programming knowledge can be characterized in the form of goals and plans that describe what must be achieved and how this is done. We have conducted interviews of spreadsheet users and analyzed spreadsheet applications qualitatively. The analysis resulted in a set of basic programming goals and plans describing spreadsheet programming knowledge. This paper introduces a model for spreadsheet programming knowledge description and uses it to present the results of our analysis.

The distinction between well-defined and ill-defined problems has its origins in the specification of components of a problem space (cf. Hayes, 1978), that is, the space of possible move sequences given the context in which the problem is set and the information-processing limitations of the problem-solver. A well-defined problem is

development methodology has received considerable attention in recent years. The adherents of XP anecdotally extol its benefits, particularly as a method that is highly responsive to changing customer's desires. While XP has acquired numerous vocal advocates, the interactions and dependencies between XP practices have not been adequately studied. Good software engineering practice requires expertise in a complex set of activities that involve the intellectual skills of planning, designing, evaluating, and revising. We explore the practices of XP in the context of software engineering education. To do so, we must examine the practices of XP as they influence the acquisition of software engineering skills. The practices of XP, in combination or isolation, may provide critical features to aid or hinder the development of increasingly capable practitioners. This paper evaluates the practices of XP in the context of acquiring these necessary Software Engineering skills.

Abstract. Building interactive software is a notoriously complex task, for which many programming tools have been proposed over the years. Although the research community has sporadically identified usability requirements for such tools, tool proponents rarely document their design processes and there is no established reference for comparing tools with requirements. Furthermore, the design of most tools is strongly influenced by the design of their underlying general purpose programming languages. These in turn were designed from their own set of little-documented requirements, which adds to the confusion. In this paper, we provide a review and classification of the requirements and properties expected of interactive development tools. We review how designers of APIs and toolkits for interaction-oriented systems set the usability requirements for the programming interface of their systems. We relate our analysis to other studies in related domains such as end-user programming, natural programming, and teaching. 1