Pair programming can be superficially defined as two programmers working together on a user story: two programmers, one keyboard, one computer. More and more often in teams that I start working with as Mentor, I see pairs of programmers who talk and talk and talk. They talk a lot. The keyboards rest and the monitors wait. The two people talk. Actually, what the keyboards and monitors don’t know is that those two over there are scheming to commit a crime: to kill the code.

The truth is, neither one is clear on just how to do it, much less brave enough to do it alone.

That's why both of them think it’s a great idea to work in pairs. "I wouldn't know what to do next, and neither do you... let's decide what to do together." They're looking for mutual protection and reciprocal approval. When the going gets tough, they support one another with quips like, "Well, there may be 30 lines in this method, but it’s better than nothing." "Whatever, someone will get rid of this IF sooner or later." "No big deal if this servlet opens the db connection, calculate the premiums and send back the estimate on the insurance policy that we're supposed to implement. Didn't Beck always say to do the simplest thing?" The two programmers will find a way to justify any abomination. It's a bit like a child with his finger in the jar of cherry jam on the top shelf in the kitchen. He suddenly realizes his mom is watching, and instantly knows, as soon as their eyes meet, that he'll get a smile.

"Mamma Programming" is what I've decided to call this way of ending up an accomplice in bad design solutions through pair work. With Mamma Programming, two programmers in front of a keyboard and a computer are accomplices in finalizing the execution of a user story. Thanks to reciprocal and silent agreement of each partner in the pair, teams commit more and more violent crimes against the code.

Caught red handed, the two programmers defend themselves against any accusations with the alibi of "refactoring debt" due to either an impending deadline, or a system (a.k.a. the "monster" ) that's become too complex over time. At this point they'll propose some sort of plea bargain, like spending one afternoon a week doing "community service" to try to refactor some bits and pieces of the “monster”, obviously, reiterating their crimes and maternally supporting one another.

Mamma Programming means looking to your partner to share responsibility. Pair Programming means trying your own path, taking on responsibility yourself. Mamma Programming means "I have no idea, let's do it together." Pair Programming means "I have an idea, I'm going to see it through." Mamma Programming means supporting your partner's idea. Pair Programming means "grabbing the keyboard away" from your partner when his idea doesn’t work and you want to try your own.

What are the causes of Mamma Programming? Lack of knowledge in terms of object-oriented design, lack of experience in problem solving, lack of responsibility.

Advanced Mamma Programming leads to test-code-n-fix, a dangerous degeneration of code-n-fix. Dangerous because by writing tests, the team thinks they're creating "good" code, while the complexity of the code grows with the silent consensus of the pair.

What should you do when you detect Mamma Programming in your team?

Mamma Programming isn’t easy to eradicate. You have to attack on several fronts:

• Increase programmers' preparation in object-oriented analysis and design.
• Increase the programmers' sense of responsibility.
• Increase programmers' level of self-esteem.

It could be useful to rotate pairs more often, but if Mamma Programming is deeply ingrained, switching does little good. In the worst cases, pair work should be suspended. This might seem like a contradictory suggestion, but remember that the goal of XP is to be effective, and not to "do XP". It's important to encourage this action with adequate training support on object-oriented analysis and design. By doing so, in a few weeks' time the team will be able to handle Pair Programming.