Paired Programming . . . for Agile Lawyers?

In my recent, limited, and recreational study of software development, I've come across a lot of concepts that were, for lack of a better word, strange. That is not to say that they are bad. Just the opposite. In fact, learning about different methodologies has really got my gears turning about some of the processes that are commonly used in legal practice, or even in my own studies. Nevertheless, it can be difficult to try and borrow software dev approaches and imagine them applied in legal practice. I think the cultural differences between the industries, perhaps stereotypical differences, may be partially responsible. With a little imagination, however, it can be done;being .



One idea that has really stuck with me the past couple days (after reading ) comes from the school of thought, more specifically, the methodology: . Paired programming is essentially the idea that pairs of programmers work so closely together that one can pick up or modify the work of their partner at any time. Advocates of paired programming insist that this method produces more code in the long-run when compared to programmers who work individually. This is a question that seemingly remains up for .




Aside from the quantity of production, there is the issue of quality. Paired programming aims to make each part of of a project's code as clear and understandable to each partner as possible. Further, programmers who work together can learn from one another and potentially develop better practices than could be learned individually. Paired programming also, in a way, facilitates knowledge management and reduces the need for a supervisory individual outside of the pair.



All of this goes to say that paired programming, in theory and when performed with discipline, produces greater quantity and quality. So the question that I've been walking around with for the past few days is, "would this produce the same results for lawyers?" I have no idea. First and at least in my experience, law students (and I'd guess a lot of lawyers) prefer to work alone. Moreover, I am willing to bet that the idea of two lawyers simultaneously billing a client while one sits and "spots" the other is enough to make some people sick.



That said, I think there could be potential value in paired lawyering, particularly for less experienced attorneys. For instance, paired programming requires that code is written so clearly that it can be picked up by another programmer without pause. What a great concept for legal writing: write clear enough so that another lawyer can pick right up from where the other left off without hesitation. This requires a succinct and simple explanation of often complex issues, which should promote a document's persuasive quality or strength.



Moreover, attorneys working in tandem can learn from each other's strengths and weaknesses and potentially develop better habits in research, writing, and client counseling. Paired lawyering may also create an environment of greater accountability and transparency, as each attorney's work is so closely tied to the success of the other. And finally, paired lawyering may reduce the need for more senior attorney review because two lawyers of equal level (I'm picturing two associates) can catch weaknesses in work product that the other may be too invested to notice.



I'm sure there are some great reasons, aside from double billable hours, that can be argued in the case against paired lawyering, but it would be interesting to see how this approach, borrowed from software development, would affect the metrics oflegal work, both quantitatively and qualitatively. This idea needs refinement, but maybe this is just one of the ways that lawyers (in my case, law students) can learn from our friends in the world of software and product development. More on this to come.
Full Post