Syllabus
Goal
Software development outside of a university class involves code that spans decades (Windows is 27 years old!), teams that span countries, and a lot of bottom-up project management and decision-making. Our goal is to help you grow your software development skills by providing an experience that matches real world software development as closely as possible. Think of it as a bit of an internship during the semester, with a strong mentoring component. We hope that this will be a different kind of class, in a good way.
Specifically, by the end of the course:
- You will have experience contributing to a real-world, large-scale software project.
- You will have participated in a geographically disparate development team, coordinating online.
- You will be familiar with large-scale project workflow using git.
- You will have practiced debugging unfamiliar systems.
- You will gain an understanding about open source project management.
- You will be confident finding and fixing bugs in other people’s code, and contributing the fix back to the project.
Course Elements
Team Projects. This class is being taught in conjunction with several universities and open source projects. Each of you will be on a team with other students (from MIT and elsewhere) working on one of those projects. You will be mentored by the teaching team and a representative from the open source project.
Student teams will work on improving their projects in two ways. First, by fixing “low hanging fruit” bugs that already exist, to get up to speed. Then, by identifying and pursuing new functionality for the project.
Hands-On Lectures. For the first few weeks, lectures will contain exercises that help you develop project workflow, debugging, and software design skills.
Weekly Meetings. For the majority of the semester, class time will be used to hold mentoring and agile project management meetings.
Course Schedule (tentative)
The full calendar is not available yet but the rough outline for the semester is:
Week 1 – Bootup
Teams choose a name (and song, and mascot!), collaboration framework, and create a simple project homepage.
Every Week – Progress report.
Teams post a short update on their progress from the last week along with any links to demos to the FB group for the course.
1/3 Point – Software demos and rapid prototypes due.
Students show their classmates what they’ve accomplished so far and get feedback on future implementations
2/3 Point – Software demos and “Contract of Deliverables”.
Other students are encouraged to use the software and report and any enhancement requests using a issue tracking tool of ce provided by the student team. Students, teaching team, and mentors collaborate to produce a description of the software that will be completed and how the functionality will be validated.
Final – Software Delivery.
At the end of the course, we publish the project outcomes by team name. There is no final exam, but expectations for what was developed should be very clear from the weekly meetings.
Grading Policy
The relative contributions to your grade will be:
60% – The code you contribute to the open source project you are working for. Our goal is to provide a real-world learning experience, so we will try to grade you like a manager would. Your code will be graded based upon:
Whether it meets the functional expectations you have set in weekly meetings and planning documents
Its robustness, and your responsiveness to any bug tickets filed about your code
The code quality, design, and project management skills you have demonstrated.
Note that you will not be alone throughout the process but supported by your mentors.
25% – Community Participation.
- Open Source projects cannot exist without a strong community of both users and developers. Engaging in the community around the Open Source project you choose to work on is the best way to know what the project needs and how you could help. Participating in mailing lists, discussion forums, or any other communication channels that project members use is the best way to really know what is going on in the project.
15% – Class and Group participation.
- Attendance and participation in your project group.
For any non-group work, each student has a total of 5 slack days to use throughout the semester. In unusual or emergency circumstances, contact a member of the teaching team to discuss an extension, which we will provide if appropriate.
Group projects cannot be turned in late under any circumstances. If you experience problems in your team, either due to team dynamics, absences, or any reason, contact the teaching team for advice on how to proceed.
In line with the Departmental Guidelines Relating to Academic Honesty, here are our expectations regarding collaboration and sharing. This class involves almost exclusively group work. You may draw upon ideas from anywhere to complete this work, but the work you perform must be your own. Any material or code taken from external sources should be properly attributed. (If a block of code is borrowed from Stack Overflow, for example, full attribution with a back-link should be made in the code comments.)
While the projects are a fully collaborative effort, we expect each member of the team to participate in every phase of development, and we will expect to see code authorship in particular attributed to the different team members. We will use the commit logs in the version control method of your choice as a primary guide to measure code contribution. You will also be asked to keep track of your participation in the community.
Except in the context of a project team, you may not reuse any materials that were developed by other students in the course, in this term or previous terms, nor may you provide work for other students to copy. Copying work, or knowingly making work available for copying, is a serious offense that may result in reduced grades, failing the course, and disciplinary action.
Credit
This class provides 12 credits and 12 Engineering Design Points. It counts as a lab for EECS.