DSLAB Projects Guide
The goal of semester projects and theses is for you to learn the research process and contribute to the lab’s research by applying that process. This involves (1) obtaining in-depth knowledge, (2) trying out new ideas, and (3) communicating your results. You will be working on a topic related to what the lab is doing, so we will be there to help, and we will also expect you to produce interesting results.
We grade projects based on your work during the semester, your results such as code and interesting ideas, and your report. During the semester, you should take ownership of your project and manage your time independently. Any code you produce should be documented enough for others to pick up where you left off, and should have enough tests and documentation for others to be convinced it is correct. Your report should concisely and clearly present the context, the problem, and the solution. We strongly encourage you to propose new ideas both during your project and in the report for potential future work by others.
Here are some examples of cool things students have done with us in the past:
- Verifying data structures and operating system components as part of the Vigor project
- Making automated program analysis more widely applicable as part of the S2E project
- Automatically finding the root cause of bugs as part of the Gist project
What you can expect from us
It is your project and you own it start to finish. We will provide you with guidance and help you whenever you are stuck. If you need advice on how to proceed, if you are out of ideas, or if you are stuck on an implementation issue, send an email to your supervisor about it. Do not be afraid to interrupt us, if we are busy at the moment we may reply later.
We will also happily chat with you if you have ideas about the project, or questions about the general research area you are working in.
There is a delicate balance between asking your supervisor too often and too rarely. You should only ask after trying to solve your issue yourself, such as searching for solutions on the Web, trying out some ideas, and asking your friends and colleagues if you are working in a shared space. On the other hand, you should not spend too much time trying to solve a problem if you have no idea how to proceed, and your supervisor will often be able to quickly point you in the right direction thanks to experience. In general, ask for help if you have been stuck for a few hours without progress. Tell us what the problem is, and which ideas you tried.
What we expect from you
We expect you to have some independence during your project, and we are trusting you with taking ownership and initiative. You should be the main driving force behind your project.
We are interested in results, not in you spending a fixed amount of time in front of your computer. Learning to estimate how much time a task takes and to manage expectations is a fundamental part of any project. We of course know that, aside from Master theses, you are not going to spend all of your working time on the project.
We know that life does not always go as planned, so please tell us if you cannot work as much or as well as you would want to. We will work with you to find a solution, but we need to know that there is a problem. You will be our colleague during your project, so we expect you to let us know in advance if you will not be available, just as we will let you know if there is something on our side.
EPFL also imposes some requirements on you, such as semester deadlines or formatting requirements for thesis cover pages. We expect you to proactively handle these, asking for our help if necessary.
You will have a weekly meeting with your supervisor to discuss what you’ve done in the elapsed week, and what you’ll be doing in the upcoming week. This is also a good time to ask high-level questions and to propose any new ideas you have. Meeting earlier is also possible if you are stuck. This is similar to the sprint debriefs we teach in the Software Development Project course.
We ask you to keep track of your progress in a progress report shared with your supervisor, such as a Google Doc, in which you write a short paragraph summarizing what you did each week. To allow us time to prepare for the weekly meeting, please update the report at least 2 hours before the meeting. This is useful for both you and us: it allows you to remember what you’ve done, which is particularly useful when it feels like you have not gotten anything done even though you worked hard on leads that did not pan out, and it allows us to know what you’ve done, so that we can better guide you towards the overall goal. It’s a good idea to write down your progress and new ideas as they happen, instead of stressing out to write it just before the meeting.
At the beginning of your report will be a list of project goals you agree on with your supervisor. This list can evolve with time, but any changes must be agreed upon by both you and your supervisor.
Your project report, which will be your thesis if your project is a Master thesis, should be a summary for everyone, including the lab and future project students, to know what you did, why you did it that way, how you did it, and what interesting discoveries you made. Target your report at the level of knowledgeable classmates, not expert researchers, unless your report turns into a research paper.
For instance, the research paper “A Formally Verified NAT Stack” published at the SIGCOMM KBNets workshop was an evolution of a Master thesis done in the lab, and helped influence the later “Verifying Software Network Functions With No Verification Expertise” paper published at SOSP, which is a top conference in computer systems.
Structure your report in six parts: (1) an introduction to the problem, summarizing any necessary background material, (2) a description of your design, explaining how it helps solve the problem as well as any design choices you made, (3) a description of your implementation, in enough detail that one can understand the overall picture without having to read your source code, (4) an evaluation, including any benchmark results, (5) a discussion of the results, including interesting insights you gained and how you think your result could be extended or improved in the future, and (6) a list of the references you used in the rest of the report.
Your report should not exceed 10 double-column pages in 11-point font, unless you really believe the added length is worth it. Keep it as short as you believe is appropriate, do not pad with filler text to reach a target page count. We prefer reading a short and concise report than a long and repetitive one, given the same amount of content.
Your supervisor can help you with the report, so feel free to send drafts for feedback, both at the beginning when you only have an overall structure and at the end when you are almost done.
Depending on your project’s outcome and on the lab’s availability, we may ask you to present your project during one of our lab meetings. The goal is to give you an audience to discuss your results, and to give the lab an idea of what these results are. We are especially interested in any unusual, unexpected, and interesting findings, even if they do not directly relate to the results.
Your code should include a “read me” file with (1) an overview of the code architecture, such as which modules do what and how the modules are tied together, (2) all instructions necessary to run your code, and (3) all instructions necessary to benchmark or otherwise evaluate your code. The audience for this file is any future lab member or project student who might need to reuse your code.
Your code should be correct and easy to understand, but it does not need to meet “production” requirements such as API documentation or fully automated installation instructions. It’s fine to merely link to your dependencies along with an explanation of how to install and configure them. We would rather you spend time getting interesting results than tediously documenting every small thing.