An Example Exploratory Interface

Here it is: exploratory interface for Timer_v2.js

The systems we make and test have all sorts of ways that we can explore them. Each way of exploring will reveal different problems. If we want to explore a unit of a system, we might start with unit tests, and write a few more to explore. I tend to adapt unit tests to use bulk input and simple oracles. The unit tests are my exploratory interface.

There are other possibilities, so here's an example, and a story.

I built a toy; CadenceKeeper.

CadenceKeeper uses several JavaScript source files – a central one is Timer_v2.js. I wanted to explore that unit on its own; I had an impression that the timers didn't always change their behaviour as they aged, and preferred to experiment and play rather than to predict and observe.

Anthropic's Claude-3.5-sonnet built me this exploratory interface for Timer_v2.js. I gave it the code, and asked for an HTML page which:

• shows the constants in use
• lets me construct new objects (that's what the code does) with parameterised and default values
• lets me select from objects I've made, and shows me its values in real time
• lets me trigger and monitor events described in the code
• gives me a simple UI for any callable method in the code

If memory serves, I had to ask a few times before I had something I felt I could use. All those bits are there, most of them folded up.

Using my cheap new tool, I mucked about with the working code, found a couple of handy bugs, fixed them and moved on. I found it swift and interesting to prompt for the interface, dig for the problems, write the right tests to expose them and then fix the problems. I found it particularly helpful, when making code-based confirmatory tests, that I had already understood how to trigger the problem and how to look for its symptoms. I would have been unlikely to write an interface like this by hand, because it would have been a yak (and a half).

Instead, it was an ephemeral tool: I wished it into existence, I used it, I threw it away.

And then I got it back out of the bin and posted it here. It didn't work at all, because my code had already moved on, so I rewound the version of Cadence Keeper back to the older one. It probably never did work, perfectly – but it worked well-enough for me to sniff out evidence, it works well-enough to let you explore how it feels, and its cost was marginal.

The tininess of that cost is what mattered when I made it: I could give my attention to exploration, not to the code nor to the tooling.

If you want to use this tool, you'll need to explore the tool, and be mindful of the difference of exploring they system it wraps round. Hard for you, easy for me because I'm the builder. Good enough.

Expect this page and this example to change. Next time I do this interestingly, I'll capture the details so I can write about them with clarity. And there's an exercise coming, so that you can build your own interfaces. Indeed, work is afoot with several valued colleagues to do this in public at an event near you...