Notes from Empirical Studies of Programmers, Second Workshop, and some ideas

April 22, 2009

Programming and Algebra Word Problems: A Failure to Transfer

Gary M. Olson, Richard Catambrone

Learning to program does not improve your algebra.

Understanding Procedures as Objects

Michael Eisenberg, Mitchel Resnick, Franklyn Turbak

First-class procedures are a difficult concept for students.

Mental Representations of Programs for Student and Professional Programmers

Robert W. Holt, Deborah A. Boehm-Davis

Two critical aspects of program comprehension: The mental representation of the program and the information-gathering process.

Communication breakdowns and Boundary Spanning Activities on Large Programming Projects

Herb Krasner, Bill Curtis, Neil Iscoe

Breakdowns in communications between politically separated units can hinder productivity.

A methodology for studying software design teams: An investigation of conflict behaviors in the Requirements Definition Phase

Diane B. Walz, Joyce J. Elam, Herb Krasner, Bill Curtis

Issues are often left unresolved and re-raised in later meetings. Clients are not homogeneous in their desires, even if there is one requirements document.

Comprehension Strategies in Programming

Nancy Pennington

Cross-referencing—thinking about both the program and the domain—produces the best program comprehension.

Categories of program information to examine:

  • Low-level Operations
  • Variables
  • Control flow
  • Data flow
  • State
  • Goals

Understanding of control flow & procedures precedes understanding of goals.

More study of a program moves understanding from procedural to goals.

Construction of a domain model is essential to comprehension.

Graphical vs. Textual Representation: An empirical study of novices’ program comprehension

Nancy Cunniff, Robert P. Taylor

Novices comprehend graphical representations of programs much better than text, especially re: control structures.

An analysis of the on-line debugging process

Murthi Nanja, Curtis R. Cook

Experts understand a program before changing it and fix multiple bugs at once.

Novices proceed stepwise, isolating candidate bug locations and fix one at a time.

Change episodes in coding: When and how to programmers change their code?

Wayne D. Gray, John R. Anderson

The more planning needed for a piece of code, the more changes are likely.

Changes in code or intention are most likely as an interrupt to coding, as a tag-along to another change or as a byproduct of execution.

Programmers almost never interrupt their coding to change already-completed code.

Reasoning, problem-solving and decision processes: The problem space as a fundamental category

A. Newell

Coding and other problems can be viewed as searches through a problem space.

Ideas generated by the above readings

  1. Normally better program comprehension means easier program modification. I think DSLs break this: They increase program comprehension, but I bet they make (some) program modifications much more difficult due to the lack of tool support in the most DSLs.
  2. How much does confidence matter in debugging and program modification tasks? Can I make someone more likely to succeed by convincing them they’re smart enough to succeed?
  3. Is there a review out there of (cognitive) theories of programming?

Q: Did you only read the abstracts, introductions and conclusions?

A: Yes.

Advertisements

3 Responses to “Notes from Empirical Studies of Programmers, Second Workshop, and some ideas”

  1. Greg Wilson Says:

    1. Is there evidence that DSLs increase comprehension? If not, there’s a study.

    2. Yes — plenty of evidence in many other areas (see Carol Dweck’s work).

    3. Don’t know; if you find it, please let us know.

  2. Edward Ocampo-Goodinh Says:

    Solid. I’d read another entry like this.

  3. Ian Says:

    Interesting set of paper summaries. I can see DSLs as being a barrier too – you need to have a reasonable working level in the DSL to be able to understand what is going on.


Comments are closed.

%d bloggers like this: