Last night, while talking with Mike Roberts and Martin Fowler the topic of Pair Programming came up. We are all proponents of Pair Programming, but inevitably the question came up concerning when Pair Programming isn't recommended. I've always liked the suggestion that any activity that requires an artist can be done more accurately/effectively while pairing.
It's not uncommon to hear that developing software is an art. This is a general statement that is often true, but it's the tasks that don't require an artist that I believe can be done without pairing. What tasks don't require an artist? I would say any task that has only one right answer. For example, the task "Table Users needs an index on the Login column" likely only has one correct implementation. Adding an index can be done a few different ways, but I expect a project has a convention on altering tables and adding the index in that way is the correct execution of the task.
I do believe tasks that have only one correct answer can be done without a pair, the tricky bit is finding tasks that have only one correct answer.
"I do believe tasks that have only one correct answer can be done without a pair, the tricky bit is finding tasks that have only one correct answer."
ReplyDeleteAh, so identifying tasks that don't need a pair is a task that requires a pair? ;)
It's obviously not worth it to split up to do something quick like add an index. Having a laptop or second computer immediately available allows for easier transitions quickly in and out of pairing, looking stuff up separately, etc. I wonder if you think it makes it TOO easy not to pair and just work next to each other, though.
I think that while developing any software surely there will be dozens of tasks that wouldn't require pairing. The problem is that those are generally part of a bigger task, a story probably.
ReplyDeleteFor those that have their own stories I think it might be worth to get only one dev taking care of it; but the act of splitting and pairing people to perform the little ones would take more time than actually solving those.
Phillip Calçado
I agree in principle that things that "don't need an artist" can be done without a pair.
ReplyDeleteBut the decision as to whether or not to pair on something should not become a discussion too often. Developers should organically make that decision and pair-up again when those tasks are done or if complications arise. One key consideration in this decision is mentoring/knowledge transfer.
From a planning perspective though, I would still assume that every story needs a pair. Trying to manage something at that fine-grained a level up-front is simply a waste of time, IMO.
I'd actually suggest that any task that has an already known and unquestionable method to it's execution is something that doesn't require a pair.
ReplyDeleteIf there's any questions (like "what is the best way to add the index such that it'll be upgraded correctly in the next release?", "what file should it go in?", "do we refactor our db migration scripts?", etc) then pairing is often going to be the better approach.
Although - I think there is two exceptions. Sometimes I think spiking creative solutions can be better done as a single developer. As long as it's a spike, which is just to come up with an idea, that will then be refined and implemented by a pair. This is just to allow a single person to explore an idea that he might not be able to initially fully explain to a pair.
I also think that sometimes (and only very sometimes) complex refactors can be undertaken by a single developer, as long as the result is clearly communicated to the team and critiqued before it is committed to. This is to allow a single 'visionary' the flexibility to mould the code into a new structure, which they might not be able to initially fully describe to a pair, but is ideally simpler and easily described and demonstrated on completion.
Aptly enough, just last week we had a situation where one programmer did something almost identical to adding an index, and did it in such a way that it required a pair to clean it up. The solo guy picked a task, "add lock_version field to table foo". (We're using Rails, and the lock_version field is how Rails does optimistic locking.) When he added it, he neglected to specify "not null" and "default = 1". In itself this is not a huge deal, but every other lock_version field in the database does it that way, so they violated a (admittedly small) coding convention. A few days later, a pair encountered that code, and we had to spend a few minutes digging around and trying to figure out whether he had done that on purpose or not. We concluded it was just a mistake, corrected it, and moved on. If the original coder had had a pair, there's a good chance the pair would have corrected him up front.
ReplyDeleteWhat's the moral of this story? Well, to appeal to authority,
"Programs must be written for people to read, and only incidentally for machines to execute."
Abelson & Sussman, Structure and Interpretation of Computer Programs
Or, to put it more concretely, pair programming is about much more than just solving a problem. It's about keeping each other honest, reminding each other of process tasks ("Do you have a test for that?" "Let's refactor." "Can we check in yet?"), and reaching not only *a* correct answer, but reaching the curve that fits the maximum of both partners' abilities across all dimensions of the solution space.
Plus it's more fun :-)
(P.S. I do agree that there are some tasks that can be done without a pair, but that decision should be reached by *both* partners, and only after it's already been started. And Chris is correct that spikes do not require a pair (that's canon XP, btw, since spikes are not production code & should be thrown away and rewritten test-first before checkin)).
I think the issue is not whether the task can be done without a pair - after all almost all programming tasks can (unlike physical tasks such as lifting large objects) - but whether value is added by having a pair. Choosing that value can often be non-quantifiable (which is probably why many organizations struggle with the concept) after all though I could carry out many benign tasks solo (add key x to table y) I would always value a pair even if it is merely for the sake of sanity and company.
ReplyDeleteMy other point is that it is very rare that a task exists in isolation as a simple instruction. Often that task has resulted from some (artistic/pair) process to arrive at the solution and even then when implementing the solution you and your pair may obtain some shared enlightenment.
I agree with Chris. When you are preparing for something [unknown territory] through a spike, it is better the pair split up, spend time individually and re-group [after agreed upon time]. I have found this to be useful than letting one person get [stuck in]/[fond of] one way of implementation without properly evaluating alternatives.
ReplyDelete