The research project is the primary artifact of the course; the outcome of all projects will be a research paper (maximum 5 pages without references). Depending on the class size, the projects may be completed in groups of up to three. The intent of the project is to identify one or more research questions, be able to motivate them, investigate the research questions and report the results in a scientific manner.
Project Proposal Draft A one-page proposal for your project to me. The course assistant and I will provide you feedback in a one-on-one meeting. The proposal has to include the problem/motivation for the project, the research question(s) and how you aim to address the research questions(s). This draft is important to be able to discuss the project ideas and help you express your ideas and us to understand what you are trying to do. However, the content and ideas are a lot more important than the formatting.
Final Project Proposal A one-page proposal for your project (two-column format, see also Written Report format below). Basically, this will be a revised version of your original draft, including the comments from the meeting.
Proposal Presentation. A short (max. 5 mins) presentation of the proposed project to the class. The goal is to share and discuss your ideas with multiple people.
Intermediate Drafts of the Report. To provide feedback on your results and write up early on, there will be intermediate steps for writing the final project report.
Written Report. The report includes your research project, the motivation, the research question(s), and the related work. The required length of the written report varies from project to project, but is at maximum 5 pages. This page limit does not extend to the references or any non-critical supplementary material you wish to include in an Appendix (e.g. survey questions). All reports must be formatted according to the ACM format and submitted as a PDF in ACM paper format (two-column style).
All authors should use the official “ACM Primary Article Template”, as can be obtained from the ACM Proceedings Template page. LaTeX users should use the
sigconf option, as well as the
review (to produce line numbers for easy reference by the reviewers) options. To that end, the following LaTeX code can be placed at the start of the LaTeX document:
Project Presentation. A presentation of the completed research project to the class.
Project Objective - Better Understanding and Supporting Developers
- Identify a real problem developers face and/or investigate a specific aspect of software development.
- Read related work and determine what has already been done and how your project is different (you can also replicate previous work).
- Identify a relevant and interesting research question and determine how to address the research question, e.g. which kind of tool support to build and how to evaluate it, what kind of study to conduct and which data to collect to address the RQs.
- Perform the analysis / Build/Evaluate the tool.
- Write up the results in a scientific way, including the motivation, related work, analysis, results and more.
Possible Project Topics
Below is a list of possible project topics. This is a good starting point for a project, but feel free to come up with your own idea and we are happy to guide you.
Note, there is the opportunity to develop tool support for developers, e.g. something for the IDE or independent of the IDE that is based on developers' work patterns or (biometric) developer data and that can support developers in their work. We have sensors and monitoring tools that you can also use for this and possibly extend (the tools).
Some rough potential research questions:
- Is pair programming "better" (more efficient, produces higher quality code, ...) than individual programming and a peer code review?
- Does Developer Turnover affect quality in Open-Source Software?
- Do code annotations improve performance of coding tasks?
- How do breaks affect focus / productivity of developers?
- Which type of break (walk / reading news) is better during programming tasks?
- Can we detect difficult code using heart-related measures?
- Can we automate certain steps of developers' workflow with a bot?
- Can we detect when developers get tired (and possibly wake them up with music or something similar)?
Biometric Sensor Projects
A few types of biometric sensors are available to use in a hands-on project. You would design a small study to answer a research question or develop an approach to take advantage of some of the data, e.g. a visualization of an interesting aspect of the sensor data or an approach to analyze an aspect of development using the biometric data.
The E4 is a wearable wrist band that offers real-time physiological data acquisition, enabling researchers to conduct in-depth analysis and visualization. More information can be found here.
Wearable wrist band that offers real-time data on heart-related measures and movement/activity.
Muse EEG Sensor
- (Copyright by Interaxon)
The Muse EEG sensor captures the electrical activity of the brain, which can indicate certain mental states as high cognitive load or relaxation. More information can be found here.
We have several Tobii 4C eye-trackers that one can use to develop support, e.g. in the form of navigation/focus support for developers.
Developer Productivity, Analysis & Retrospection
- Gather data from software developers using an approach like PersonalAnalytics and analyze a question on developers, e.g. about their productivity, workflows or work fragmentation
- Extend PersonalAnalytics (or a MacOS version) with another kind of data / kind of insight.
- Develop your own self-reporting / retrospection app for productivity and well-being and evaluate with a few participants.