Various programming environments feature live programming as a central part of their programming experience. Liveness in these environments is analyzed by several theories, which describe the different forms of liveness and how they influence the programming experience. Unfortunately, these are isolated theories only concerned with live programming features. They can not explain liveness in terms of general interactions with programming tools.One theory that has successfully explained how programmers interact with various kinds of tools is information foraging theory (IFT). In this paper, we propose an IFT interpretation of liveness. By interpreting liveness in terms of a more comprehensive theory of programmer behavior, we can explain the role of liveness in common software development activities such as debugging.We have explored our IFT interpretation of liveness in a first controlled experiment. We investigated the hypothesis that when we remove liveness from live dynamic introspection tools, programmers will use them less often, as using them has a higher cost. We have conducted a post hoc analysis of the results for which we used the edit-run-cycle model adapted to analyze the usage of live programming tools. The post hoc results hint that programmers did shift away from introspection tools. While our study only features post hoc results, it suggests that the IFT interpretation of liveness is a fruitful avenue.

Programmers regularly explore the execution of code examples to verify assumptions by adding print statements or commenting in and out setup code in their implementation to isolate code paths of interest. In our formative study on developing embedded programs, where proximity to hardware dictates low abstraction levels, we observed that wrong assumptions occur frequently. However, traditional editors for embedded programs lack support for such explorations. Consequently, programmers have to re-create and clean up setup and print statements in their code for each example.

Formal specifications like TLA+ support software developers in formulating and verifying properties of their systems as state machines. Writing specifications helps software developers incrementally develop an understanding of their systems’ domains. However, according to our formative study, while reading such specifications authored by others, software developers tend to struggle to build comprehension. To overcome the limitations of text, participants visualized specifications and manually constructed concrete example sequences of actions. We propose an approach that visualizes state-machine-based specifications to better support software developers in reading, exploring, and understanding them. Our tool, SpecTacles, generates and presents interactive visualizations derived from a specification’s state space next to its original source text. Users can formulate example sequences of actions, which are synchronized between all visualizations. To explore how and why such interactive visualizations help, we conducted a user study ($\mathrm{n}=12$) with software developers who had no prior training in formal specifications, and explored how they use our tool in a set of comprehension tasks. Participants used the source text to obtain local and definitive information, for example, to validate an assumption, but they referred to the visualizations to gain an overview and to compensate for the lack of control flow information in the source text. Given the strengths of both visualizations and source text, participants found SpecTacles useful for their comprehension and indicated that they would like to use it in other software engineering contexts.

Structured editing can show benefits in learnability, tool building, and editing efficiency in programming. However, creating a usable structured editor is laborious and demanding, typically requiring tool builders to manually create or adjust editing interactions.

Researchers conducting studies on programming tools often make use of maintenance tasks. The complexity of these tasks can significantly influence how participants behave. At the same time, the complexity of tasks is difficult to pinpoint due to the many sources of complexity for maintenance tasks. As a result, researchers may struggle to deliberately decide in which regard their tasks should be complex and in which regard they should be simple.To help researchers deliberately influence task complexity, we discuss different factors of task complexity. We draw these factors from 23 selected and 39 surveyed studies on programming tools. We arrange the factors according to a task complexity model from ergonomics research that we adapt for maintenance tasks. We illustrate the application of the factors through an example critique of a task design. In the end, task complexity might always be too complex to be fully controlled. Nevertheless, we hope that our discussion helps other researchers to decide in which dimensions their tasks are complex and in which dimensions they want to keep them simple.

Debugging is an essential part of software development. Numerous tools and techniques to improve debugging have been proposed in research or developed in the industry. However, only a few of those see widespread use, and debugging only rarely is a primary teaching subject.

Crochet is still purely manual. While other crafts such as knitting or weaving have received technical support, the process of creating instructions for new crochet patterns is barely supported by domain-specific, digital tools. Those tools are constrained by their underlying crochet pattern languages that are either ambiguous or limited in their expressiveness. As a result, creating crochet instructions requires substantial manual effort and can result in incomplete or ambiguous instructions after all.

Creating structured editors, which maintain a valid syntax tree at all times rather than allowing to edit program text, is typically a time consuming task. Recent work has investigated the use of existing general-purpose language grammars as a basis for automatically generating structured editors, thus considerably reducing the effort required. However, in these generated editors, input occurs through menu and mouse-based interaction, rather than via keyboard entry that is familiar to most users.

Game development benefits from short iterations, as it is often concerned with how a game will feel like; something that is hard to anticipate. Live programming aims at reducing the length of iterations during software development to allow for faster exploration and improve program comprehension. We propose a live game development environment providing a more general live programming workflow in game prototyping. The environment supports developers in two aspects: how will a code change affect the look and feel of the game and how does the behavior of the game relate to its code? The proof-of-concept environment ensures short feedback cycles by always keeping the game running while it is being developed. We propose several mechanisms to work with the running game, for example, programmers can automatically replay situations in the game by using an explicit notion of snapshots. We tentatively demonstrate the effectiveness of the live programming features in the context of the development of game prototypes of different genres.

The software engineering practice of automated testing helps programmers find defects earlier during development. With growing software projects and longer-running test suites, frequency and immediacy of feedback decline, thereby making defects harder to repair. Regression test prioritization (RTP) is concerned with running relevant tests earlier to lower the costs of defect localization and to improve feedback.

Under-resourced urban communities regularly struggle with their municipalities about water. To empower citizens in their position in the water system, we propose a mobile application called "Drop Drop" which allows users to track their own water usage by reading their meter. We developed an initial prototype iteratively and evaluated it in a two week field study in the community of Makhaza in Cape Town. We found that the concept is generally feasible and useful for citizens to understand their water usage and their water meter. However a major challenge is to find an effective way how the application can provide training on reading a meter and on entering the reading.