Productivity Lecture Overview

The productivity lecture is a bit difference from other lectures: it includes in-class participation and focuses on scientific theories related to productivity differences.

Bring A Laptop

You should bring a laptop to the lecture. It should charged in advance and network capable. Install all of your favorite development software on it.

Required Reading

There are six required readings for this special lecture, but for each one I draw your attention to particular parts of the document. The intention is not that you read everything, but you should come prepared for a discussion on this material.

  1. Walter Dougherty and Ahrvind Thadani. The Economic Value of Rapid Response Time. IBM Systems Journal, 1982.
    • Pay special attention near: "the number of transactions a programmer completes in an hour increases noticeably as system response time falls, and rises dramatically once system response time falls below one second."
    • What does Figure 2 tell us?
  2. H. Sackman, W. J. Erikson and E. E. Grant. Exploratory Experimental Studies Comparing Online and Offline Programming Performance. Communication of the ACM, 1968.
    • Pay special attention near: "one poor performer can consume as much time or cost as 5, 10 or 20 good ones" (Section 1.3.2).
    • Then, take a look at Table I (Experienced Programmer Performance). How do you interpret a mean of 4.0 hours with a standard deviation of 4.3?
    • This paper is generally interpreted as reporting 10:1 ratios between best and worst on productivity metrics and 5:1 on program speed and space metrics.
  3. Frederick Brooks. The Mythical Man-Month. Addison-Wesley, 1975/1995.
    • (Full text courtesy of The Internet Archive.)
    • Pay special attention to Chapter 8 ("Calling the Shot") -- especially Corbato's data. What is this saying about the average number of lines of code per day produced by a programmer (including testing and debugging, etc.)? Is this reported number what you expected?
  4. M. Chi, R. Glaser and E. Rees. Expertise in Problem Solving. Advances in the Psychology of Human Intelligence, 1982.
    • Pay special attention near "Physics Problem Solving and Expertise" (page 16). For example, consider "The expert often does this in one step" and "The speed with which a problem can be solved ... Simon and Simon (1978) noted a 4:1 difference between their expert and novice".
    • Pay special attention near "There is also some evidence that the chunk is associated with a "fundamental principle" of physics, such as Newton's Second Law".
    • Finally, read near "aspect of novice problem solving is not only that they commit more errors than experts but that, even when they do solve a physics problem correctly, their approach is quite different".
  5. U. Debarnot, M. Sperduti, F. Di Rienzo, and A Guillot. Experts bodies, experts minds: How physical and mental training shape the brain. Frontiers in Human Neuroscience, 2014.
    • Focus on the section entitled "Functional Plasticity Characterizing Novices and Experts". For example, what does "These results suggest that the disparity between the quality of the performance of novice and expert golfers lies at the level of the functional organization of neural networks during motor planning." mean?
    • Then focus on the section entitled "Experience-Dependent Structural Changes in the Human Brain". How applicable are golf, juggling, dance and music results to computer science?
  6. E. Murphy-Hill, C. Jaspan, C. Sadowski, D. C. Shepherd, M. Phillips, C. Winter, A. K. Dolan, E. K. Smith, M. A. Jorde. What Predicts Software Developers’ Productivity? Transactions on Software Engineering, 2019 .
    • Focus on RQ1 "What factors most strongly predict developers’ self-rated productivity?". Note Job enthusiasm, Peer support for new ideas, and Useful feedback about job performance.
    • Then focus on discussions like "A notable outcome of the ranking is that the top 10 productivity factors are non-technical. This is some- what surprising, given that most software engineering research tends to focus on technical aspects of software engineering, in our estimation. Thus, a vigorous refocusing on human factors may yield substantially more industry impact for the software engineering research community."