Pair programming dilemma

Pair Programming happens to be one of the first casualties when shops hastily jump into agile bandwagon. (TDD/Test Driven Development is another). Maybe because it’s counterintuitive to many. The whole effectiveness of pair programming gets questioned (How can two working together not be wasting time?). Even Dilbert had his say.

Now with agile way of development gaining more ground, in all flavours – offshored, distributed, CMMised, PMIed, whatever – resistance to any practice can only weaken the whole concept of agile and squeezing the last drop out of it. (Though pair programming is not strictly tied to agile method and one can happily do it in non-agile settings, it gained more mileage piggybacking agile)

One way to counter counterintuitiveness is with empirical studies. Or with studies which explains why it works.

Stuart Ray has come up with such a brilliant article on pair programming which dives into cognitive science to explain how pair programming works. The article delves beautifully in the workings of brain and human behavior, and perhaps corroborates the fact that brain is more a social organ and cannot but feel better with increased chance of social interaction. He goes on to advance four mechanisms of pairing.

One is “Pair programming chat“. It seems talking about programming problems, even to oneself, helps getting unstuck. Stuart Ray goes on to give a wonderful cognitive rationale behind it with language module doing the trick with integrating knowledge held in other modules.

Carruthers suggested that we must rely on the language module posing the right question and that the other modules don’t usually present in­formation spontaneously. However, when we hear the right question, our brains make the nec­essary information available, and the language module can then perform rudimentary inference and draw the obvious conclusions. Carruthers suggested that the key is posing a question that’s “both relevant and fruitful.” The right question draws forth the crucial knowledge, and in a mo­ment of epiphany, the answer becomes obvious.

Next being “Pair programmers notice more details“. In this Stuart Ray talks how more details gets noticed under pair programming. So, two people programming together won’t have the same prior knowledge or categorization: one will presumably spot some things faster and the other different things. That is till pair fatigue sets in.

Then comes “Fighting poor practices“. Pair programming can nudge programmers to follow best practices or rather, to avoid poor practices. In his words, Pair programmers might be less susceptible to poor practices because they can promise to write code in a particular way and ensure that each other’s promises are kept.

And finally, “Sharing and judging expertise”. Programming is one area where you never know how skilled one is unless you get to work together with her. Stuart Ray argues rightly that the individual skill levels become transparent in a team which does peer programming. This argument might also help in managing or rewarding performance of people at individual level.

I tried to find some empirical studies on effectiveness of pair programming. In one study in Norway, 295 programmers were used to do a controlled experiment on pair programming. The results of this experiment do not support the hypotheses that pair programming in general reduces the time required to solve the tasks correctly or increases the proportion of correct solutions. On the other hand, there is 84% increase in effort to perform the tasks correctly. However, on the more complex system, the pair programmers had a 48 percent increase in the proportion of correct solutions but no significant differences in the time taken to solve the tasks correctly. I believe the experiment missed out on a significant factor of pair programming effectiveness increasing with gelled teams and shared context, which is expected in real projects.

In one study to analyze cost and benefit for pair programming, Alistair Cockburn and Laurie Williams, found that for a development-time cost of about 15%, pair programming improves design quality, reduces defects, reduces staffing risk, enhances technical skills, improves team communications and is considered more enjoyable at statistically significant levels. To justify economics, the authors stresses the point that pair/collaborative programming reduces defects by a huge margin even if there is small increase in development effort, which in the end compares favorably cost-wise towards pair programming.

It will only help to consider such studies (or better trying it out) before ditching pair programming just because it happened to be counterintuitive to conventional wisdom. It will be a shame if in a rush to get agile branded shops cherry pick agile practices instead on building a foundation of right culture. It might help in sales gimmicks but not in greater good of agile.


Shine on you crazy windows

“What do you want?” Goetz asked.
“Give me five dollars,” Canty replied.
Goetz looked up and, as he would say later, saw that Canty’s “eyes were shiny, and he was enjoying himself……Goetz reached into his pocket and pulled out a chrome-plated five-shot Smith and Wesson .38, firing at each of the four youths in turn.

Malcolm Gladwell, in his fine book ‘The Tipping Point‘ explains the Power of Context’  “is that we are more than just sensitive to changes in context. We’re exquisitely sensitive to them.” Human behavior owes a lot to the context or situation, rather than, say, personality or genetic makeup. And that explains a lot in provoking Goetz, a decent New Yorker, shoot four youths in a graffiti ridden, littered subway train in one cold december day in New York.

Power of context is best summed up by the Broken Windows theory. Gladwell writes 

“Broken Windows theory and the Power of Context are one and the same. …The Power of Context is an environmental argument. It says that behavior is a function of social context….The Power of Context says that you don’t have to solve big problems to solve crime. You can prevent crimes just by scrubbing off graffiti and arresting fare beaters…Once you understand that context matters, however, that specific and relatively small elements in the environment can serve as Tipping points …..”

Broken Windows theory is the brainchild of criminologist James Q.Wilson and George L.Kelling, and in their own words:

“Social psychologists and police officers tend to agree that if a window in a building is broken and is left unrepaired, all the rest of the windows will soon be broken. This is as true in nice neighborhoods as in run-down ones. Window-breaking does not necessarily occur on a large scale because some areas are inhabited by determined window-breakers whereas others are populated by window-lovers; rather, one unrepaired broken window is a signal that no one cares, and so breaking more windows costs nothing. (It has always been fun.)”

Kelling was later hired by New York Transit Authority, who together with subway director David Gunn cleaned up the graffiti. Later William Bratton, hired as transit police head, another disciple of Broken Windows, cracked down upon farebeating. All these attributed in bringing down New York crime radically during the mid-80s.

In order to discover if signs of vandalism, litter and low-level lawbreaking could change people’s behavior, Kees Keizer and his colleagues at the University of Groningen conducted experiments to, say, validate Broken Windows theory.

His group’s first study was conducted in an alley that is frequently used to park bicycles. ..the researchers created two conditions: one of order and the other of disorder. In the former, the walls of the alley were freshly painted; in the latter, they were tagged with graffiti ….In both states a large sign prohibiting graffiti was put up, so that it would not be missed by anyone who came to collect a bicycle. All the bikes then had a flyer promoting a non-existent sports shop attached to their handlebars. This needed to be removed before a bicycle could be ridden. When owners returned, their behaviour was secretly observed. There were no rubbish bins in the alley, so a cyclist had three choices. He could take the flyer with him, hang it on another bicycle (which the researchers counted as littering) or throw it to the floor. When the alley contained graffiti, 69% of the riders littered compared with 33% when the walls were clean.

Do the Broken Windows theory and Power of Context apply to an organization? Can we radically improve the organizational environment to foster professional behavior? Hoarding information, dirty office politics, taking undeserving credit, favouritism, all can be broken windows. Bringing right culture is a lot of fixing broken windows.

Software development is notoriously known for falling quickly into tar pit.

In the book The Pragmatic Programmer, Andrew Hunt and David Thomas look into Broken Windows in software developments:

“There are many factors that can contribute to software rot. The most important one seems to be the psychology, or culture, at work on a project. Even if you are a team of one, your project’s psychology can be a very delicate thing. Despite the best laid plans and the best people, a project can still experience ruin and decay during its lifetime. Yet there are other projects that, despite enormous difficulties and constant setbacks, successfully fight nature’s tendency toward disorder and manage to come out pretty well.”

Bad design, wrong decisions or poor code can be broken windows, which warrants fixing as soon as they are discovered. Agile development framework like Scrum is good in the way that the underlying framework makes fixing broken windows highly desirable. High order of transparency and rapid feedback mechanism with continuous integration, pair programming, daily scrums all encourage fixing broken windows.

Let the windows shine.

Agile – real or placebo?

Is Agile software development just a placebo effect ? Do we get better results because we expect and believe things will get better? Or is there something more to Agile?

Linda Rising continues to enthrall us in seeing agile way of developing software in a different perspective. Earlier it was aping the ape, which gave us new insight in seeing teams.

This time she ponders if the same belief system which makes placebo work in medicine makes agile work in software development.  She believes that the belief system in agile makes many good things happen in agile.  Sheep, it seems, are the believers.

Though I found it interesting, I found it difficult to see the direct connection. Nevertheless it raised some beautiful questions which makes you think. But at the end of the day – does it matter? She says it doesn’t.

Behavioral economist Dan Ariely devotes a chapter on placebo in his book Predictably Irrational . Quote from it: “Placebo comes from the Latin for “I shall please.” The term was used in the fourteenth century to refer to sham mourners who were hired to wail and sob for the deceased at funerals. By 1785 it appeared in the _New Medical Dictionary,__ attached to marginal practices of medicine”. Dan Ariely says, two mechanism shape expectations that make placebos work, one is belief and other is conditioning.

How will a patient react if she knows she is on placebo? How will an agile developer react? If agile is offering placebo, what reason is there to believe that waterfall didn’t? After all, more managers backed waterfall than agile. If placebo is defined as pseudo-treatment with real cure, which part of agile is really pseudo?

Anyway, whatever the questions are, it’s refreshing to see Dr.Linda Rising bringing forth another interesting perspective.