Programmer Information Needs After Memory Failure

Reviewed by Leif Singer / 2012-07-04
Keywords: Refactoring, Tools, Usability

Parnin2012 Chris Parnin and Spencer Rugaber: "Programmer information needs after memory failure". 2012 20th IEEE International Conference on Program Comprehension (ICPC), 10.1109/icpc.2012.6240479.

Despite its vast capacity and associative powers, the human brain does not deal well with interruptions. Particularly in situations where information density is high, such as during a programming task, recovering from an interruption requires extensive time and effort. Although modern program development environments have begun to recognize this problem, none of these tools take into account the brain's structure and limitations. In this paper, we present a conceptual framework for understanding human memory organization and its strengths and weaknesses, particularly with respect to dealing with work interruptions. The framework explains empirical results obtained from experiments in which programmers were interrupted. The intent is to use the framework to design development tools capable of compensating for human memory limitations. We also delineate programmer information needs such tools must satisfy and suggest several memory aids such tools could provide.

Parnin and Rugaber discuss several cognitive challenges that probably every developer has faced at some point: tracking many code locations at once while doing a big refactoring, or trying to remind ourselves to continue work on a certain problem when an external event has occurred. For these challenges, they give examples for coping strategies that, again, probably every programmer has used one time or the other. We send reminder e-mails to ourselves, add // TODO comments that we forget about later, or deliberately create compiler errors as an anchor into our current task.

The authors analyze and classify these challenges and coping strategies using existing research from neuroscience. The result is a theoretical framework that is mostly interesting to researchers and a few practitioners who wish to create better developer tools. Wearing my researcher hat, I cannot help but to instantly try thinking of neat ways to leverage this framework as a designing aid for developer support mechanisms.

However, when I put on my developer hat, I realize that it's even more than that. Parnin's and Rugaber's framework helps me reflect upon my own programming habits and provides some explanations for their existence. For example, why is it that so many TODOs remain in code for so long, never to be DONE? They are passive reminders that are never triggered!

Even without the tool support that Parnin and Rugaber are creating, their paper provides an interesting look at ourselves as developers, our habits, our weaknesses, and our coping strategies. In doing so, it raises our awareness for these issues and inspires us to slight modifications of our work practices that are better tailored to our human brains. The next time I write a TODO, I'll make sure to create an automatic reminder as well.