CS 846 logo: Human Aspects of Software Engineering

Software is a human product. Developers are intrinsic to software development; as systems scale in size and complexity, the challenges that developers must overcome rapidly increase. This course will examine why creating software is a hard problem and how these problems have been addressed and evaluated both in research and practice. We will focus on development-based activities (rather than planning or requirements-based activities). The course will be seminar-based and will involve weekly reading and discussion. The project component will be flexible but will likely involve some programming. This course is offered by the David R. Cheriton School of Computer Science at the University of Waterloo.

Lectures are held Thursday mornings from 09:00 to 11:50 in DC 3313. My office hours are TBD but will be held in DC 3351. Official administrative entry.

Important dates and information will be posted to the course twitter feed.


The best way to get in touch with me is via email.

Nominal Outlinetop

The course will be adjusted according to your feedback, interests, and experience. This is an overview of the kinds of topics we could cover:
  • software evolution
  • program comprehension
  • software visualization
  • development team processes
  • software development tools and environments
  • quantitative & qualitative evaluation of software engineering research

Tentative Course Scheduletop

It is important to note that this schedule is very susceptible to change based on your interests and how the class is progressing.

Thursday September 15 - Introduction

Thursday September 22 - Background

  1. Brooks. No Silver Bullet. Computer, vol.20, no.4, April 1987.
    Presented by Reid Holmes
  2. Gibbs. Software's Chronic Crisis. Scientific American, September 1994.
    Presented by Reid Holmes

Thursday September 29 - Information needs

  1. Ko, DeLine and Venolia. Information needs in collocated software development teams. ICSE 2007.
    Presented by Areej Alhothali
  2. Fritz and Murphy. Using information fragments to answer the questions developers ask. ICSE 2010.
    Presented by Jason Baek

Thursday October 6 - Code search

  1. Reiss. Semantics-based code search. ICSE 2009.
    Presented by Phil Mitchell.
  2. Starke, Luce, and Sillito. Searching and Skimming: An Exploratory Study. ICSM 2009.
    Presented by Ahmed El-Roby.

Thursday October 13 - Graph views

  1. Murphy, Notkin and Sullivan. Software Reflexion Models: Bridging the Gap between Source and High-Level Models. FSE 1995.
    Presented by Andre Carrington.
    Andre also recommends a [Supplemental Paper] relevant to his presentation.
  2. Bragdon, et. al. Code Bubbles: Rethinking the User Interface Paradigm of Integrated Development Environments. ICSE 2010.
    Presented by David Dietrich.

Thursday October 20 - Tasks

  1. Kersten and Murphy. Using task context to improve programmer productivity. FSE 2006.
    Presented by Claude Richard.
  2. Fritz, Ou, Murphy, and Murphy-Hill. A degree-of-knowledge model to capture source code familiarity. V Y.
    Presented by Rahul Sharma.

Thursday October 27 - GSSE

  1. Herbsleb, Mockus, Finholt, & Grinter. Distance, dependencies, and delay in a global collaboration. CSCW 2000.
    Presented by Dan Dexter.
  2. Bird, et. al. Does distributed development affect software quality? An empirical case study of Windows Vista. ICSE 2009.
    Presented by Kevin Shelley.

Thursday November 3 - Assorted

  1. Xing and Stroulia. Refactoring practice: How it is and how it should be supported: an Eclipse case study. ICSM 2006.
    Presented by John Morcos
  2. Guo, Zimmermann, Nagappan, and Murphy. Moving into a new software project landscape. ICSE 2010.
    Presented by Vajih Montaghami
  3. Dagenais et. al. "Not my bug!" and other reasons for software bug report reassignments. CSCW 2011.
    Presented by Angela Chan

Thursday November 10 - Questions

  1. Robillard, Coelho, and Murphy. How effective developers investigate source code: An exploratory study. TSE 2004.
    Presented by Chang Sheng-Dean.
  2. Sillito, Murphy and De Volder. Questions programmers ask during software evolution tasks. FSE 2006.
    Presented by Abdullah El-Sayed.

Thursday November 17 - Tools

  1. Holmes and Walker. Customized awareness: recommending relevant external change events. ICSE 2010.
    Presented by Noha El-Prince.
  2. Begel, Khoo, and Zimmermann. Codebook: Discovering and exploiting relationships in software repositories. ICSE 2010.
    Presented by Oleksii Kononenko.

Thursday November 24 - Project presentations

Some groups have expressed interest in doing presentations for their project. These will be optional but will give you the chance to help others better understand what your projects are all about. The presentations should be between 10 and 20 minutes.

Thursday December 1 - PC Meeting

Course Formattop

This will be a paper-based seminar course. Each week we will read and discuss two papers. Everyone in the class will have an opportunity to give a 15-20 minute paper presentation (this comprises 30% of your mark) and lead the ensuing discussion. While only one person will present each paper, it is expected that everyone will read the papers to contribute to the discussion.

While reading the papers you should be able to answer the following five questions:

  1. What were the primary contributions of the paper as the author sees it?
  2. What were the main contributions of the paper as you (the reader) see it?
  3. How does this work move the research forward (or how does the work apply to you)?
  4. How could this research be extended?
  5. How could this research be applied in practice?
While presenters should keep these questions in mind, the audience in particular should think about them specifically while they are reading the paper.

You will get to select the paper you want to present from the course. This selection can be made from this list. Once you have selected a paper, choose a day and add yourself to the following lecture schedule. This must be done by September 16 @ 0800.

The project is the primary artifact of the course; the outcome of all projects will be a research paper. In the last week of the class we will formally review all the papers from the course projects (using standard program committee review forms) and have a PC meeting describing the strengths and weaknesses of each paper. The reviews you produce will comprise 20% of your final mark.

The course will conclude with a formal Program Committee (PC) meeting. All projects will be submitted via a EasyChair (a conference management system). Each paper will receive at least 8 reviews from class members (I will review every paper). These peer-reviews will comprise 20% of the final mark. Michael Ernst has compiled a series of informative links for creating effective reviews. Here are links to two different reviews as well (one positive and one negative) if you want concrete examples.

Remember, the reviews must all be submitted to Easychair by 0800 on Nov 30.


The project forms an integral part of this course. The projects can be completed in groups of up to three. The intent of the project is to identify some

Three types of projects are possible:

  1. Build a Software Tool:

    The goal of this style of project is to identify some problem developers encounter in practice, find some solution, and validate that the solution helps with the initial problem. I would recommend drawing upon your experience as you write code to identify some problem that has inhibited you in the past and fix it.

    The outcome of this project will be a short (5-6 page) paper describing the problem, your solution, a comparison to related approaches, and some form of validation.

  2. Literature Survey:

    The goal of this kind of project is to gain a more complete understanding of a topic relevant to this course. The outcome of this project will be a critical summary of the state-of-the-art on your selected topic; this summary should be 8-10 pages. It is essential that this summary synthesizes the surveyed literature to identify important themes, findings, and open questions.

  3. Use an Advanced Software Development Tool

    The goal of this project is to provide a validation of some previously-existing development tool from the research community. The tool you validate must be related to the course material. The outcome of this project will be a 6-8 page paper describing your experience with the tool outlining its strengths, weaknesses, and avenues for future improvement.

There are two deliverables regardless of the kind of project you choose:

  1. Project proposal. Before you undertake your project you will need to submit a proposal for approval. The proposal should be short (1-2 pages in ACM format). The proposal should include a problem statement, the motivation for the project, a set of objectives you aim to accomplish, and a set of milestones. I will read these and provide comments. The proposal is not for marks but _must_ be completed in order to pass the course.
    This will be due on October 3 @ 0800 via email.
  2. Written report. The required length of the written report varies from project to project; all reports must be formatted according to the ACM format and submitted as a PDF. This artifact will constitute 100% of the project grade.
    This will be due on November 21 @ 0800 via Easychair.
  3. Project presentation. This is optional.
    Each group will have the opportunity to present their project in class on November 24, if they want to.
    This presentation should take the form of a 10 minute conference-style talk. There will be time for questions after the paper has been presented. The talk will not count for marks.


Paper presentation: 30%

Project: 50%
Due Nov 21 @ 0800

Paper reviews: 20%
Due Nov 30 @ 0800


Academic Integrity

  • In order to maintain a culture of academic integrity, members of the University of Waterloo community are expected to promote honesty, trust, fairness, respect and responsibility. [See the academic integrity site for more information.]


  • A student who believes that a decision affecting some aspect of his/her university life has been unfair or unreasonable may have grounds for initiating a grievance. Read Policy 70, Student Petitions and Grievances, Section 4.
  • When in doubt please be certain to contact the department’s administrative assistant who will provide further assistance.


  • A student is expected to know what constitutes academic integrity to avoid committing an academic offence, and to take responsibility for his/her actions.
  • A student who is unsure whether an action constitutes an offence, or who needs help in learning how to avoid offences (e.g., plagiarism, cheating) or about “rules” for group work/collaboration should seek guidance from the course instructor, academic advisor, or the undergraduate Associate Dean.
  • For information on categories of offences and types of penalties, students should refer to Policy 71, Student Discipline.
  • For typical penalties check Guidelines for the Assessment of Penalties.


  • A decision made or penalty imposed under Policy 70 (Student Petitions and Grievances) (other than a petition) or Policy 71 (Student Discipline) may be appealed if there is a ground.
  • A student who believes he/she has a ground for an appeal should refer to Policy 72 (Student Appeals).