I looked for existing work and opinion on code review using tablets today.
I started by looking for people who do what I do at work – print out the code to be reviewed. It looks like I’m not very unusual in thinking this is a worthwhile thing to do, in fact the practice seems almost common. But I haven’t felt great love for printouts out there.
Gonsalves and Murthy (2001) say a couple of interesting things:
The reviewer should not try to fix any bugs or improve the code. S/he should merely inform the programmer about potential bugs and possible improvements.
2. Steps in Code Review
1. Obtain print-outs of the specs and design documents, and of the code.
That second suggestion is interesting. If for no other reason than that it shows reviewing code using a text editor is considered inefficient by some.
Some in the wild call printouts “a conventional techniqe” or “soooo 1976”. That doesn’t surprise me, in fact I’m surprised this is not a dominant opinion. Programmers love gadgets and fancy software.
Looking at tablet code review in particular I was glad to see there isn’t much. At first I thought this is a completely unexplored idea, but then I found “A System for Developing Tablet PC Applications for Education” (2008), guys who developed such an application. The software was not made especially for code review (it’s only one use case) and I’m not sure it was ever completed (“This application is under active development. We do not know what set of features will best facilitate discussion of
each student’s code.”). There’s a note Mike might find interesting:
Our department has a required class for juniors, entitled “Programming Studio,” in which students meet each week, in small groups, to review each other’s code [13].
“Panel: Using Peer Review in Teaching Computing” mentions “Using a Tablet-PC to Provide Peer-Review Comments”, a simple experiment which found (among other things) that:
In general, we found that the most natural medium for providing comments was the paper/pen. However, that medium also invited more editing-style com- ments, which were not necessarily appropriate for the task at hand.
Good, that’s good. “Inking in the IDE: Experiences with Pen-based Design and Annotation” is mostly about drawing diagrams, but they do mention code annotations and that unfortunately they don’t work because they’re not integrated with IDEs.
“Moving Markup: Repositioning Freeform Annotations” (2006) is not about code review, they developed a system to allow for annotating text on a tablet, and mention something I like:
Freeform digital ink annotation allows readers to interact with documents in an intuitive and familiar manner. Such marks are easy to manage on static documents, and provide a familiar annotation experience.
And here’s what I was afraid of, this concept has been not only considered but implemented multiple times. “CodeAnnotator: Digital Ink Annotation within Eclipse” (2007) mention Penmarked and RCA as “limited” solutions. Also they go over their own implementation:
Bah, I really hoped I would be the first to implement something like this. Oh well.
“A Pen-based Paperless Environment for Annotating and Marking Student Assignments” (2006) describes Penmarked. Again – it looks like just an implementation, with no serious evaluation of its efficiency.
“RCA: Experiences with an IDE Annotation Tool” is about (surprise) RCA. Thankfully this is also only an implementation. These guys integrated it with Visual Studio. Doesn’t look like it’s gone beyond a research project.
I can’t take it any more, I will have to continue later. Maybe saturday. Just looking at the long list of references in the papers above makes me sick.