Another reason for licensing programmers
Written on 12 Aug 2008
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.
Filed in: Software culture, Test-Driven.

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.