Pair Programming vs. Code Reviews

Jeff Atwood over at Coding Horror is asking for comments on the relative efficiency of these processes. We do both at my company, and while I don't think I have anything truly original to add, I come down on the agile side of the discussion (which should not be surprising to you if you read this blog often!)

The comments are already coming in complaining about pairing. I noticed these two particularly:

the obvious conclusion to this is double the hours per project, at minimum (and I'd expect that you would work slower if you had to discuss or explain stuff to someone else the whole day).

I would freak out if someone would watch me every the time I code (and also has a keyboard to interupt me lol)

Sort of the standard responses to pair programming. I'm not so experienced at the art that I can really say the hours don't double, maybe they do - but what I can say is even if the hours are doubling, the code quality is squared. Maybe it's just a commentary on what lousy code I produce by myself, but there is a big difference when someone else is there looking at the code, even if it's only the "navigator" effect, where the person who isn't actually at the keyboard can allocate the memory space to go back and remember any refactorings or other cleanup that needs to be done. As far as working slower, there are only two possibilities: first, that the other person doesn't know about the code as well as you do, in which case the knowledge transfer makes the whole thing worthwhile, or second, that there are a few ways of doing things and you need to decide which way is best. The selection you make when coding by yourself might easily not be that one.

even if the hours are doubling, the code quality is squared.

Freak out if someone watched you code? Dude, is your code really that bad?

Insofar as code reviews go, I find them almost unnecessary when pairing. Some teams do peer-review-before-checkin, which I don't really care for - I just can't grok the concept the code is trying to get across just from staring at it for a few seconds while someone explains it to me, but I suppose some people can do that. But we do code reviews for two things: first, to go over legacy code - we have plenty of that in our application - and second, to go over code that's just been checked in. This isn't 100% useful either, but on the other hand we have very few development meetings, and sometimes it's worth it just so someone can point out, "Oh, this should have been done using this brand new language feature" or, "we have a custom library that already handles exactly this case, can we use it here?"

So code reviews can be worthwhile, and they are absolutely necessary in a non-pairing environment. The big thing to watch out for is that you don't spend a lot of time discussing what your internal coding standards are, as I've written about before. But my feeling is that it is not as useful as pair programming.

Javadoc Clutter

Ed Gibbs, one of my favorite bloggers, writes on the usefulness of javadoc comments. (I meant to write on Alfred Thompson's thoughts on the issue last month as well, but didn't get to it.) Here's my take: If you're coding properly, you have lots of little methods, as Ed says, and they should be just about self-documenting and not really in need of comments. But, when you have code organized like this, it becomes even more important that the big picture be kept in mind somewhere. This partly means working on good class-level documentation - how the class is intended to be used for example, but it also means having good diagrams of the entire application. With this, you may realize not only how the class is intended to be used, but how it's being used in an unintended way, or how it's duplicating the functionality of this other class over here and they need to be merged into a single class.

So where do the diagrams come from? As Alfred mentions, you can use class designers like the one in Visual Studio, but my feeling is that that is only a starting point. There are so many different diagrams you can make: dataflow, inheritance, etc., but you have to keep in mind that the point of any diagram is to help the reader grok the system. What I like to do is keep a documentation wiki around, and generate some diagrams that can be added as pictures, and as a starting point for some user-defined text to help explain them.

But when you do that, eventually you're going to want hyperlinks in the text that lead back to the class, and its description, and its methods. And this is where Javadoc comes in. In the build, throw in a step that generates HTML pages from the Javadocs, and make them available to the users of the project wiki. I think this gives you the nicest combination of high-level overviews and class-level references, both of which are essential to a well-managed project.

The 20 Dumbest Words in Software Development

Brandon McMillon writes on doing it right. (Thanks to Alfred Thompson for the link.) He doesn't touch on the agile side of software development - although I can guess his opinion by his planned article "Pair Programming is for Morons" - and so the article has a lot of stuff about Objectives and Requirements and Spending Design Time Up Front. The tricky bit about commenting on this sort of article is that I don't really disagree; his straw man comparison is that one group who just goes off and starts coding so they can get it done faster. That is bad. He does mention how getting sign-off and buy-in from users and stakeholders is valuable, and here's where we might differ: getting this sort of data is important throughout the life of the project, not just somewhere near the front. Because once a user gets some working software in his her hands, she's immediately going to have ideas to improve it, and they'll probably be good ones. So, while it's nice to do some designing up front, it's more important to have your code in a state where you can make changes easily and quickly, to respond to the inevitably changing user requirements.

What I have written here is short, and therefore oversimplifies the many issues. But the full range of agile practices can answer most objections, in my experience.

Evaluating Javascript in an NUnit test

Adam Esterline posted his solution to javascript testing. He uses WatiN to run tests, which I wasn't excited about; I was hoping for a way to test where I didn't have to install any more software anywhere. Here's the solution I came up with:

static object Evaluator(string code )
{

ICodeCompiler compiler;

compiler = new JScriptCodeProvider().CreateCompiler();
CompilerParameters parameters;

parameters = new CompilerParameters();
parameters.GenerateInMemory = true;
parameters.GenerateExecutable = true;

parameters.ReferencedAssemblies.Add(Assembly.GetExecutingAssembly().Location);

CompilerResults results;

results = compiler.CompileAssemblyFromSource(parameters, code);
if (results.Errors.Count > 0)
     throw new Exception(results.Errors[0 ].ErrorText);

Assembly assembly = results.CompiledAssembly;

MethodInfo entryPoint = assembly.EntryPoint;

return entryPoint.Invoke(null, new object[] { null } );

}

[Test]
public void EvaluatorTest()
{
  Evaluator( "Context.Current.Data = \"Craig\"" );
  Assert.AreEqual( "Craig", Context.Current.Data );
}

This seems elegant and able to handle a lot of things like side effects. Unfortunately I've been back on the server side for the most part and haven't really tried to put this code through its paces.