James Bach writes:

“It was interesting to me that the developers who came to the Agile Fusion conference initially professed interest in pairing with testers, but their enthusiasm seemed to wane as they learned that testers are critical thinkers– and critical thinkers are disruptive. When I paired with programmers, I mostly adopted a programmer mindset, because I didn’t want to freak them out.

On the context-driven testing mailing list, James elaborates on the disruptive nature of testing:

Try this experiment. Stand behind someone who is writing a memo. Every time they mistype something, tell them. Also tell them immediately about any grammar mistakes. Also comment on their writing style. Periodically stop them and question the whole purpose of the memo. Speak any risks you think of along the way.

I think you will find that the person you are “helping” gets annoyed. Their train of thought will be broken. The same kind of thing happens if we sit with programmers who are writing code. The same kind of thing happens in requirements and design meetings. There is a value to proceeding speculatively and creatively for protected periods of time, without being assailed by critical thoughts.

(posted with permission)

This sentence really got me thinking about tester/developer pairing, and how we can add value to the development process: “There is a value to proceeding speculatively and creatively for protected periods of time, without being assailed by critical thoughts.” I’m not sure that we could or even should pair constantly with a programmer, but there are times when it seems to work very well.