malvasia bianca

A little while back, I wrote some about the pros and cons of deliberate practice, as per the book Range. Deliberate practice works well if you’re working on something with a clear goal, where you have fast and accurate feedback loops; but if you’re not working in a domain like that, then deliberate practice might not get you working in an effective direction.

So yay: that lets you know when deliberate practice is a good idea, when it isn’t. The thing is, though: having fast and accurate feedback isn’t an inherently immutable characteristic of a problem domain! Like, as medicine developed precise tests and forms of measurement, I would imagine that larger and larger portions of becoming an effective doctor became amenable to a deliberate practice approach.

In a domain that’s much more familiar to me, I feel like this shift is a big part of what’s going on with Test-Driven Development. If you’re approaching a programming question starting with the idea of “I want the software to do something like this, so I’m going type some code that feels like it should accomplish that, and then I’ll deploy it and poke around and hope that it does that thing (and also that it doesn’t crash)”, then you’re pretty far away from the sorts of characteristics where deliberate practice approaches are effective. The feedback loops in that scenario are long, and not particularly precise. (If you’re poking around through the UI of the software, it’s very easy to miss paths through the software, paths that could have unexpected behavior, paths that could crash.)

If you’re doing TDD, though, you’re doing something that’s different in at least two important ways: you’re phrasing your questions in a much more precise way, setting up the possibility of much more precise feedback; and you’re shortening your feedback cycles from minutes (or hours or days or longer) to seconds. So the feedback / learning / practice cycles start looking a lot more like the situations where a deliberate practice style approach works.

Don’t get me wrong, this doesn’t mean that TDD is a panacea. Even if you’re good at applying it, there are going to be questions that TDD won’t answer: maybe business metrics questions, maybe usability questions, maybe broader questions around architectural interaction. Brian Marick’s Testing Quadrants are one touchstone here; TDD is about the bottom left quadrant, and there are three other quadrants involved in testing, along with concerns that are broader than testing!

So, yes, exploratory testing is still a thing, it’s still extremely valuable, and it maps a lot more to the approaches described in Range than to a deliberate practice approach. But leave exploratory testing for bigger questions, questions where it’s harder to quickly get precise answers. The more you can design your programming processes so that as much learning as possible happens in short precise trustworthy cycles, the faster your learning as a whole will go.