Programmer Information Needs After Memory Failure
Reviewed by Leif Singer / 2012-07-04
Keywords: Refactoring, Tools, Usability
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
TODOs remain in code for so long, never to
DONE? They are passive reminders that are never
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
TODO, I'll make sure to create an automatic
reminder as well.