Moldable Development Patterns

Moldable development supports decision-making by making software systems explainable. This is done by making it cheap to add numerous custom tools to your software, turning it into a live, explorable domain model. Based on several years of experience of applying moldable development to both open-source and industrial systems, we have identified several mutually supporting patterns to explain how moldable development works in practice. This paper targets (i) readers curious to learn about moldable development, (ii) current users of the Glamorous Toolkit moldable IDE wanting to learn best practices, and (iii) developers interested in applying moldable development using other platforms and technology.

Moldable Exceptions

Debugging is hard. Interactive debuggers are mostly the same. They show you a stack, a way to sample the state of the stack, and, if the debugger is live, a way to step through execution. The standard interactive debugger for a general-purpose programming language provided by a mainstream IDE mostly offers a low-level interface in terms of generic language constructs to track down and fix bugs. A custom debugger, such as those developed for specific application domains, offers alternative interfaces more suitable to the specific execution context of the program being debugged. Custom debuggers offering contextual debugging views and actions can greatly improve our ability to reason about the current problem. Implementing such custom debuggers, however, is non-trivial, and poses a barrier to improving the debugging experience. In this paper we introduce "moldable exceptions", a lightweight mechanism to adapt a debugger's interface based on contextual information provided by a raised exception. We present, through a series of examples, how moldable exceptions can enhance a live programming environment.

Example-driven development: bridging tests and documentation

Software systems should be explainable, that is, they should help us to answer questions while exploring, developing or using them. Textual documentation is a very weak form of explanation, since it is not causally connected to the code, so easily gets out of date. Tests, on the other hand, are causally connected to code, but they are also a weak form of explanation. Although some tests encode interesting scenarios that answer certain questions about how the system works, most tests don't make interesting reading. Examples are tests that are also factories for interesting system entities. Instead of simply succeeding or failing, an example returns the object under test so that it can be inspected, or reused to compose further tests. An example is causally connected to the system, is always live and tested, and can be embedded into live documentation. Although technically examples constitute just a small change to the way that to test methods work, their impact is potentially ground-breaking. We show (i) how Example-Driven Development (EDD) enriches TDD with live programming, (ii) how examples can be molded with tiny tools to answer analysis questions, and (iii) how examples can be embedded within live documentation to make a system explainable.

Learning: Moldable Development