In exploratory programming, there’s no specification or problem to be solved, but there are things to be discovered. Those programming in an exploratory way could be making art (in a generative mode) or trying to understand a topic or subject through data (in an analytic mode), or perhaps doing something that doesn’t easily fit into either category.

I call this “exploratory programming” to distinguish it from other programming practices. If you’re given an assignment to classify data using a perceptron, and you do this, this might be an educational and informative experience, and it might allow you to do further exploration in the future, but in and of itself it isn’t exploratory programming. If you are told to implement an overdraft system at a bank, or an adaptive hint system in a game, what you do to complete these tasks isn’t exploratory programming.

Also, if you specify exactly what a digital humanities system is supposed to do beforehand, apply for a grant, get funding for the project, hire programmers, and implement the system, this is also an industrial project and not exploratory programming. You might accomplish your stated goal, but you’re missing the opportunity to engage with computing as a means of innovating, as a way of learning more about humanistic methods.

Exploratory programming is a practice or phenomenon, not one piece of code or a body of code. It’s more like “pair programming,” “iterative design,” or even the game industry’s “crunch time” than it is like a specific computer program. Please adjust your critical apparatus appropriately. — Nick Montfort, Exploratory Programming – CCS Working Group 2014.