Miscomputation in software: Learning to live with errors

Computer programs do not always work as expected. In fact, ominous warnings about the desperate state of the software industry continue to be released with almost ritualistic regularity. In this paper, we look at the 60 years history of programming and at the different practical methods that software community developed to live with programming errors. We do so by observing a class of students discussing different approaches to programming errors. While learning about the different methods for dealing with errors, we uncover basic assumptions that proponents of different paradigms follow. We learn about the mathematical attempt to eliminate errors through formal methods, scientific method based on testing, a way of building reliable systems through engineering methods, as well as an artistic approach to live coding that accepts errors as a creative inspiration. This way, we can explore the differences and similarities among the different paradigms. By inviting proponents of different methods into a single discussion, we hope to open potential for new thinking about errors. When should we use which of the approaches? And what can software development learn from mathematics, science, engineering and art? When programming or studying programming, we are often enclosed in small communities and we take our basic assumptions for granted. Through the discussion in this paper, we attempt to map the large and rich space of programming ideas and provide reference points for exploring, perhaps foreign, ideas that can challenge some of our assumptions.

💡 Research Summary

The paper surveys six decades of programming practice to examine how the software community has learned to coexist with errors. It frames errors not merely as bugs to be eliminated but as phenomena that can be approached from four distinct paradigms: formal methods, scientific testing, engineering‑focused design, and artistic live‑coding. By convening a group of students representing each paradigm, the authors surface the underlying assumptions that shape each approach and explore where these assumptions converge or diverge.

Formal methods aim for mathematical certainty. Programs are modeled as logical specifications and verified through theorem proving or model checking. The authors acknowledge the theoretical elegance of this approach but highlight practical obstacles such as state‑space explosion, the steep learning curve for formal languages, and the difficulty of scaling proofs to large, evolving codebases. Consequently, formal verification is most effective when applied selectively to safety‑critical components rather than whole systems.

Scientific testing treats software as an empirical subject. Hypotheses about program behavior are validated through unit, integration, system, and property‑based tests, often orchestrated within continuous integration pipelines. Testing provides rapid feedback and uncovers regressions, yet it can never guarantee completeness. The paper stresses that test suites are limited by what developers deem testable, and that reliance on testing alone can mask deeper design flaws.

Engineering approaches focus on reliability, availability, and resilience. Techniques such as modular architecture, interface contracts, defensive programming, and fault‑isolation mechanisms are discussed. By designing for graceful degradation and rapid recovery, engineers accept that some faults will inevitably arise but aim to limit their impact. The authors note that engineering solutions depend heavily on accurate assumptions made during design; when those assumptions diverge from reality, remediation costs can be substantial.

Live‑coding represents an artistic stance that embraces errors as creative opportunities. In performance‑oriented domains—interactive media, electronic music, and visual art—mistakes become part of the expressive process, prompting on‑the‑fly debugging and improvisation. While this mindset fosters innovation and rapid prototyping, it is less suited to traditional product development where reproducibility, maintainability, and compliance are paramount.

Through the student discussion, the paper reveals a spectrum of epistemic positions: “errors can be eliminated,” “errors are discovered experimentally,” “errors are prevented by design,” and “errors are sources of inspiration.” The authors argue that these positions are not mutually exclusive. They propose hybrid strategies, such as embedding formal verification into a test‑driven CI pipeline for critical modules, or incorporating live‑coding‑style rapid iteration into early‑stage design sprints to surface hidden assumptions.

The final section offers a decision framework. Project size, domain risk, regulatory constraints, and team expertise guide the selection of an appropriate primary paradigm, while complementary techniques fill gaps. For high‑assurance systems, formal methods combined with rigorous testing and engineering safeguards are recommended. For fast‑moving startups or exploratory research, a blend of testing, engineering best practices, and occasional live‑coding sessions can accelerate learning while keeping quality in check. The authors conclude that errors should be viewed as catalysts for methodological innovation rather than mere defects, and that future software engineering will likely be defined by the seamless integration of these four perspectives.