Bumps in the Code: Error Handling during Software Development

Problems come up during software development all the time. When developers hit these bumps, situations can be surprising and new, and they must figure out what — if anything — has gone wrong. Error handling often resolves small, immediate concerns, however, findings from three ethnographically-informed studies suggest that the way developers experience errors has implications for professional growth and development. Through these experiences, developers refine ideas, strengthen collective practice, and learn

Knowledge mediation in software quality engineering

The risk of failure of the software development process remains high despite many attempts to improve the quality of software engineering. Contemporary approaches to process assurance, such as the capability maturity model have not prevented systemic failures, nor have project management methodologies provided guarantees of software quality. The paper proposes an approach to software quality assurance based on a knowledge mediated concurrent audit, which incorporates essential feedback processes. Through a tightly integrated approach to quality audit, programmers would be empowered to use any chosen methodology to advantage, supported by intelligent monitoring of the essential interactions which occur in the development process. An experimental application implementing some aspects of the proposal is described <br /

New Generation Debuggers: Défis du GDRGPL 2020

Debugging is a painful and costly practice, due to the nature of bugs, of the debugged programs, or to tools limitations. We describe several difficulties of debugging that present scientific challenges (i.e., we don't know how to do it) or technological challenges (i.e., we can't do it). We believe that addressing these challenges will lead to new generation de-buggers that will significantly ease and lower the cost of debugging

Using quicksand to improve debugging practice in post-novice level students

The ability to debug existing code is an important skill to develop in student programmers. However, debugging may not receive the same amount of explicit teaching attention as other material and the main expression of debugging competence is students' ability to undo problems which they themselves have injected into their assignments. Further, as the literature points out, debugging skills do not necessarily develop at the same rate as code writing skills. This paper discusses an intervention in a second year course designed to improve students' application of simple debugging techniques. We use a puzzle based approach where students are graded based on the number of attempts they take to locate misbehaving code in a program which they did not write but whose function they understand. An existing assignment component addresses another aspect of debugging practice

Automatic Software Repair: a Bibliography

This article presents a survey on automatic software repair. Automatic software repair consists of automatically finding a solution to software bugs without human intervention. This article considers all kinds of repairs. First, it discusses behavioral repair where test suites, contracts, models, and crashing inputs are taken as oracle. Second, it discusses state repair, also known as runtime repair or runtime recovery, with techniques such as checkpoint and restart, reconfiguration, and invariant restoration. The uniqueness of this article is that it spans the research communities that contribute to this body of knowledge: software engineering, dependability, operating systems, programming languages, and security. It provides a novel and structured overview of the diversity of bug oracles and repair operators used in the literature

How Shallow is a Bug? Why Open Source Communities Shorten the Repair Time of Software Defects

A central tenet of the open source software development methodology is that the community of users and developers is instrumental in improving the quality of software. Using a 10-year longitudinal dataset from the Firefox community, I investigate how the size of a community in terms of bug reporters and software developers, the social networks of developers and the quality of user contributions influence the time needed to repair software defects. The results show that a large open source community in terms of bug reporters reduces the time needed to resolve a defect while the addition of new software developers to an open source community takes away resources to fix bugs and increase the time needed to resolve a defect. In addition, software developers occupying dense network positions need less time to solve a bug. Finally, user contributions are beneficial when bugs are lively discussed but there is no support for the prediction that the experience of the bug reporter or the quality of the bug report reduces the time needed to solve a software defect

A Pointcut Language for Setting Advanced Breakpoints

In interactive debugging, it is an essential task to set breakpoints specifying where a program should be suspended at runtime to allow interaction. A debugging session may use multiple logically related breakpoints so that the sequence of their (de)activations leads to the expected suspension with the least irrelevant suspensions. A (de)activation is sometimes decided by some runtime context values related to that breakpoint. However, existing breakpoints, which are mainly based on line locations, are not expressive enough to describe the logic and the collaboration. Programmers have to manually perform some repeated tasks, thus debugging efficiency is decreased. In this paper, we identify five frequently encountered debugging scenarios that require to use multiple breakpoints. For such scenarios, it is often easier than using the traditional debugger to write pointcuts in an aspect-oriented language, and to suspend the execution at the selected join points. However, existing languages cannot handle the scenarios neatly and uniformly. Therefore, we design and implement a breakpoint language that uses pointcuts to select suspension times in the program. Our language allows programmers to use comprehensible source-level abstractions to define breakpoints. Also, multiple breakpoints can be freely composed to express their collaboration. In this way, an expected suspension can be expressively programmed and reached with less or even no irrelevant suspensions