CS 846 logo: Human Aspects of Software Engineering

Important Links

Complete list of papers

Paper sign-up document (Due Jan 16)

Submit seminar paper review (Due 0800 every Wed)

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 every Wednesday from 10:30 to 13:20 in DC 3313. My office hours are TBD but will be held in DC 3351. Official scheduling details can be found in the 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.

Wednesday January 7 - Introduction

Wednesday January 14 - Historical Context

  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

Wednesday January 21 - Information Needs

  1. Ko, DeLine and Venolia. Information needs in collocated software development teams. ICSE 2007.
    Presented by Alexandra Vtyurina
  2. Sillito, Murphy and De Volder. Questions programmers ask during software evolution tasks. FSE 2006.
    Presented by Sanjana Sridhar

Wednesday January 28 - Tools

  1. Ye and Fischer. Supporting reuse by delivering task-relevant and personalized information.
    Presented by Jose Calvo
  2. Goldman et. al. Real-Time Collaborative Coding in a Web IDE.
    Presented by Reza Adhitya Saputra
  3. Brun, Holmes, Ernst and Notkin. Proactive Detection of Collaboration Conflicts.
    Presented by Bastin Gomez Headmon

Wednesday February 4 - Understanding

  1. Marat Boshernitsan et. al. Aligning development tools with the way programmers think about code changes.
    Presented by Jingjie Zheng
  2. Kersten and Murphy. Using task context to improve programmer productivity.
    Presented by Atri Sarkar
  3. Hindle, Barr, Su, Gabel, and Devanbu. On the Naturalness of Software.
    Presented by Edmund Wong

Wednesday February 11 - Navigation

  1. Robillard, Coelho, and Murphy. How Effective Developers Investigate Source Code: An Exploratory Study.
    Presented by Yunjia Sun
  2. Wettel. Software Systems as Cities: A Controlled Experiment.
    Presented by Adriaan Labuschagne
  3. Reiss. Semantics-Based Code Search.
    Presented by Mina Farid

Wednesday February 18 - CLASS CANCELLED (Reading Week)

Wednesday February 25 - CLASS CANCELLED

Wednesday March 4 - Debugging

  1. Hartmann, MacDougall, Brandt, and Klemmer. What Would Other Programmers Do? Suggesting Solutions to Error Messages.
    Presented by Yuguang Zhang
  2. Johnson, Song, Murphy-Hill, and Bowdidge. Why don't software developers use static analysis tools to find bugs?.
    Presented by Raminder Sodhi

Wednesday March 11 - Code Review

  1. Bacchelli and Bird. Expectations, Outcomes, and Challenges of Modern Code Review.
    Presented by David Xu
  2. Rigby and Bird. Convergent Software Peer Review Practices.
    Presented by Brian Agala

Wednesday March 18 - Bugs

  1. Bettenburg, Just, Schroter, Weiss, Premraj, and Zimmermann. What Makes a Good Bug Report?.
    Presented by Vishal Chaudhary
  2. Guo, Zimmermann, Nagappan, Murphy. Characterizing and Predicting Which Bugs Get Fixed: An Empirical Study of Microsoft Windows.
    Presented by Aditya Ramaraju

Wednesday March 25 - Project Presentations

Wednesday April 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 20-25 minute paper presentation and lead a discussion 20-25 minute discussion about the paper. While only one person will present each paper, it is expected that everyone will read all of the papers and contribute to the in-class 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 was the work validated?
  5. How could this research be extended?
  6. How could this research be applied in practice?
Each week, you will also submit a review of one of the papers being presented that week at 0800 the day of class (by email). The summary should be 500-1000 words long. The discussion questions above (or the ones we talked about in the first class) can be used to help structure your review. While presenters should keep these questions in mind, the audience in particular should think about them specifically while they are reading the paper. Every second week you will be assigned one of the presented papers to review (this means you will perform four reviews during the term). The reviews are due at 0800 via email the day of the class. In addition to reviewing the paper, each review should include some key discussion points that you think would be interesting to talk about in class.

You will get to select the two papers you want to present from the course. Please make your selections from this list. Once you have selected your papers, enter the details in the following paper choice list. I will generate a cohesive class schedule once everyone has selected their papers.

This must be done by January 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 1400 on March 31.


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 a real development shortcoming faced by engineers and create a tool to improve this problem.

The goal of this 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.

There are three deliverables for your project:

  1. Project proposal. Before you undertake your project you will need to submit a proposal for approval. The proposal should be short (max 1 page PDF in ACM format). The proposal should include a problem statement, the motivation for the project, and set of objectives you aim to accomplish. I will read these and provide comments. The proposal is not for marks but _must_ be completed in order to pass the course. If you wish to 'pitch' to the class to find additional team mates, please indicate this at the bottom of the proposal. For the pitch you will get 1-2 minutes to describe the project to try to entice others to join your group. NOTE: even if you pitch, you are still free to abandon your project and join a different one.
    This will be due on January 28 @ 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 March 23 @ 0800 via Easychair.
  3. Project presentation.
    Each group will have the opportunity to present their project in class on March 25.
    This presentation should take the form of a 15 minute (hard maximum) conference-style talk and describe the motivation for your work, what you did, and what you found. If a demo is the best way to describe what you did, feel free to include one in the middle of the talk. There will be time for questions after the paper has been presented.

I have included a brief description of five of the projects from previous years.

  • Answering developers’ questions using information fragments in a heterogeneous development environment In this project, the authors developed a novel approach to model online programming threads (e.g., Stack Overflow). This paper was extended subsequent to the course and was published in VLHCC 2012.
  • Semantic-Based Code Search Evaluation: An Exploratory Study By evaluating three different code search engines, the authors aimed to identify high-level strengths and weaknesses that could be used to suggest future improvements for hybrid code search approaches.
  • NavTracks: The Next Generation This paper evaluated the existing NavTracks tool to determine how the tool worked in practice and to suggest future avenues for research in this space.
  • File Recommendation Based on File Interactions: A Clustering Approach to File RecommendationsA new approach for leveraging code navigation paths (in a similar manner to NavTracks) was developed and the quality of the recommended artifacts evaluated.
  • Evaluation of Canada Health Infowayʼs Message Builder API and its documentation The authors evaluated the Infoway API and documentation to gain insight into the ease-of-use of this API by end-user developers.


Seminar: 20%

Seminar Paper Reviews: 10%

Project: 40%
Due March 23 @ 0800

Project reviews: 20%
Due March 31 @ 1400

Class Participation: 10%


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).