I've never done development pairing. But I did a project once where I acted as the developer and my partner was a subject matter expert. He would define a set

I've never done development pairing. But I did a project once where I acted as the developer and my partner was a subject matter expert. He would define a set of requirements, I'd code them up and iterate releases every day or so. He'd use it for a day and either while using it, or after gathering up some notes, give me the next round of requirements. Our release cycles were measured in hours not days and we went from prototype to working-in-a-production-environment in a month. The technology we built in those three months was either bug free or all the known errata were well documented, we had manuals, well commented code, design documents, methods and operation manuals, and real world working results. It replaced a major component written a couple of years prior by a team of three developers with a faster, more robust, more portable, more extensible piece of code that coupled more tightly to the subject matter requirements while still being flexible enough for other domains. It was ported to Java by a major systems integrator for use as a critical infrastructure link between components on a $150mil/year contract and some of the components and lessons from it became important pieces in a number of other pieces of software and solutions. Another port was made for a web deployable data processing engine on another multi-million dollar contract. It was without a doubt the most prolific, most rewarding and most productive project I've ever been on bar none and I'm convinced that it was the extremely fast cycle time from requirements to working code that did it. Along the way, what we discovered is that the fast iterations quickly made us realize that requirements we thought were important initially weren't, and new important ones emerged quickly. If we had tried to set requirements and build monolithically, we would have produced code no better than the previous code because the requirements going in weren't really all that much different than what went into the original program.