Update: The paper has now been officially published at http://www.computer.org/portal/web/computingnow/0110/whatsnew/software
Stuart Wray has posted a draft of an interesting paper on How does Pair Programming Work?. I can’t judge all the psychological claims, but many of the points appeal to my confirmation bias.
In “Mechanism 3”, Wray makes a link between code-n-fix programming and a form of “operative conditioning” otherwise known as gambling. The academically respectable quotation comes from Gleitman et al.:
In a [Variable Ratio] schedule, there is no way for the animal to know which of its responses will bring the next reward. Perhaps one response will do the trick, or perhaps it will take a hundred more. This uncertainty helps explain why VR schedules produce such high levels of responding in humans and other creatures. Although this is easily demonstrated in the laboratory, more persuasive evidence comes from any gambling casino. There, slot machines pay off on a VR schedule, with the “reinforcement schedule” adjusted so that the “responses” occur at a very high rate, ensuring that the casino will be lucrative for its owners and not for its patrons.
This matches some of my experience programming, and is a pretty good explanation of some of the behaviour I see around me: the continual hope that the next fix will be the right one, the explosions of frustration when something doesn’t work, and the endless sessions. We’ve even strengthened the addictiveness with our taste for darkened rooms with flashing lights (like casino floors), and our highly responsive IDE’s.
Wray hypothesises that Pair Programming may help to manage this addiction by keeping us honest. I suspect that Test-Driven Development also helps by smoothing the flow, removing the Variable Ratio effect, and, as I wrote before, by breaking us out of the programming Tar Pit long enough to refocus on the real goal.
Perhaps we programmers should be licenced, not for the sake of our unlucky customers but to preserve our own health.
Thanks for bringing up this concept of “Variable Ratio”. I’ve seen this a lot in myself and others. Instead of taking a step back and learn and understand the underlying technology or conceptual model we go on trying things and hope that the things we try will fix the problem.
Examples:
Instead of having a whole understanding of how css works the developer tweaks a little bit in one browser to only discover that it doesn’t work in another.
Without reading the documentation and without looking at the source code to understand the inner work of a library, we try to use the library and make changes after changes with the hope that it will work.
re: “Instead of taking a step back and learn and understand the underlying technology or conceptual model we go on trying things and hope that the things we try will fix the problem.”
That’s bang-on.
The “continual hope that the next fix will be the right one”, etc. Sounds like a classic case of not understanding the problem. (Easier said than remedied, alas.)
I know the feeling only too well, as in the early 1990′s I had the extreme pleasure of maintaining ICL’s OfficePower after way too many fingers had been in the pie, so to speak. (Offending bits re-written, hopefully, in the intervening years.)
[...] This post was mentioned on Twitter by SteveF , Philip Schwarz. Philip Schwarz said: RT @sf105 Nice to see the Stuart Wray's paper published. I wrote up his comparison of coding to gambling a while ago http://bit.ly/4xajAK [...]
And tell me that the “green bar – YES!” of unit testing isn’t itself a form of pure operant conditioning?
The combination of pairing and unit tests replaces a destructive form of operant conditioning with a potentially more constructive one. However, as TDD becomes more routine and perhaps less thoughtful, the operant conditioning still functions, the psychological reward is as strong as ever, and you may not notice that the behavior is no longer as constructive as it was.
I think this is an effect that some TDD organizations start to see after several years. As in any relationship – and raising code together is a relationship – the way to keep things thoughtful is to reach beyond your comfort zone – attempt things you don’t know how to do together, things that will open up your thinking about the things you’re already doing.
@lupestro Agreed, that it’s important to keep fresh.
I think the important difference is that with TDD, the reinforcement should be regular and small-scale. The operant conditioning in code-and-fix comes from the intermittent successes scattered through all the crashes and failures.