Mark Needham

Thoughts on Software Development

Pair Programming: The Code Fairy

with 6 comments

One of the hardest situations that comes up when pair programming is when you want to solve a problem in a certain way but you can’t persuade your pair that it’s the approach you should take.

The temptation in these situations is to wait until your pair isn’t around, maybe by staying late at the end of the day or coming in early the next day and then making the changes to the code that you wanted to make but didn’t when you were pairing with them.

My colleague Cam Swords has coined this pattern of behaviour ‘the code fairy‘ and it’s something that we want to try and avoid in software development teams.

The thing to note here is that you’re following another direction than you had been when pairing, not that you’re working alone on the code just because you’re pair can’t work with you at the moment for example.

The problem with following this approach is that you lose the benefit of pairing in that you have two eyes looking at the code and reducing the likelihood of stupid code being put into the code base – by stupid I mean code which has been written with cleverness in mind rather than simplicity. I find that when I work alone those types of ideas are much more likely to seem a good idea than when I have someone else there to put me right.

When we can’t convince our pair to follow our approach it is often due to the fact that we can’t articulate why we prefer it well enough to convince them. In a recent conversation with Cam about the problem of persuading people of our approach he pointed out that even if we are really good at constructing an argument for why our approach is better our pair may still not want to do it and we can’t do a lot about it.

Most recently I’ve been really enthused by the idea of writing functional OO code but I find it very frustrating that I can’t currently clearly explain why I prefer this approach to writing code over an approach which favours there being more mutable state.

I really want to go and change the code to follow that approach but it would be inconsistent with the rest of the code base as well as being less clear to my team mates since it would have been me who wrote it alone rather than doing it in collaboration with a colleague.

Another problem is that since we ended up going and re-writing the code ourselves the same situation will happen again in the future so we haven’t really achieved anything apart from temporarily making the code a bit better in our eyes. In addition there are now less people on the team who understand that particular bit of code which is not a good position to be in when we’re working in a team.

It’s definitely not easy to resist the urge to go and ‘fix’ the code on our own but for the benefit of our team mates it’s something we need to consider.

Be Sociable, Share!

Written by Mark Needham

April 10th, 2009 at 7:28 pm

Posted in Pair Programming

Tagged with

  • Pingback: The Code Fairy - solutions/ideas - Jonathan Cogley's Blog()

  • The Code Fairy – Solutions/Ideas

  • Tom Childers

    The easiest solution is to simply involve a third engineer to break the tie.

    The most productive software development in my experience happens when team members informally form and disband work groups to solve problems. These work groups can involve 3, 4 or more engineers, depending on the size of the issue to solve, and can last for 5 minutes, hours or days as necessary.

    This kind of work environment easily occurs when (1) the team is composed of seasoned engineers without ego attachment to getting their way, (2) the team’s highest objective is code quality and “customer” satisfaction, whoever the “customer” is, and (3) the work environment (management and social values) assume that each engineer is competent, responsible, and manages time well.

    Engineers, like anyone else, rise to the level of expection placed on them.

  • I often compare pairing to being in a relationship with someone. One of most important characteristics of a successful relationship is compromise. If you can’t compromise, the relationship won’t work.

    Both pair members have to be interested in some amount of compromise.

    I often have moments where I pair with someone who doesn’t value the exact same things as I do in a codebase. I try to achieve the most important of my consideration while letting them achieve the most important of theirs.

    In the event of a major split that you feel that you can’t compromise on, you can always bring in a third person for perspective, but you it’s a bad sign if that is frequent.

    I also find going back and changing the code after the fact to be a bit of a violation of trust with the pair. They probably will see that code again, and they will know that you waited for them to be gone to write it your way.

    That’s not to say that I won’t do that from time to time, but I try to make it as rare as possible, and only when I don’t think the person discovering it later is going to bother them much.

  • Pingback: Software Quality Digest - 2009-04-21 | No bug left behind()

  • As far as using functional ideas in OO code: bugs are mostly state manipulation gone wrong. The more state manipulation there is, the bigger the window for bugs to come in to the code base. This makes functional ideas related to other ideas like limiting the scope of variables, avoiding variable re-use, avoiding ref or out parameters, limiting the number of fields in an object and so on.