EECS 498: Advanced Programming and Principles of Software Design
The University of Michigan, Winter 2026
Advanced programming techniques including polymorphism, composition, metaprogramming, exception safety, resource management. Multithreading, asynchronous control, and structured concurrency. Core principles of effective software design, including abstraction and coupling, and their realization in design patterns across programming languages and paradigms.
Instructors
| James Juett <jjuett@umich.edu> |
Course Overview
Lectures are offered in-person, with recordings posted for review.
Labs are held in-person, with a mix of pragmatic tutorials, coding practice, and group software design exercises. You'll also meet briefly with a staff member for project feature demos during some lab session.
Attendance at both lecture and lab is required for credit. Due to space constraints, you must attend your registered sections.
Projects focus on incremental development of a single, large-scale codebase. You'll complete the first portion individually, then combine to work in a consistent group of 3 for the remainder of the term.
Exams will be in-person, on-paper, at a scheduled time.
Office hours are held in-person and/or virtually. The primary intent is to provide a place for discussion, guidance, and feedback (and not necessarily for debugging support).
Communication
The course website at eecs498-software-design.org links to all course resources.
The course Discord Server is best for technical questions, discussion about course concepts and assignments, and connecting with other students, course staff, and alumni.
For extensions/exceptions, alternate exam scheduling, etc., please submit an administrative request via eecs498-software-design.org.
For other questions or concerns, email the course staff at eecs498-software-design@umich.edu.
You may reach out to course faculty directly for sensitive concerns.
Canvas is where we publish important announcements and grades. It is your responsibility to verify you can receive Canvas announcements. Please do not send messages to instructors via Canvas. It is difficult to track these messages and we want to ensure you receive a prompt reply.
Diversity and Inclusion
We care about our course community and want it to be a place where all students feel included, valued, and safe to learn from and with others. Diversity of thought and of people are important to us. We ask that you treat all other students with respect and work to create an inclusive community, and we hold ourselves to the same standard. Please feel free to contact us with any problem, concern, or suggestion. You may also report any concerns or misconduct via the resources linked at https://cse.engin.umich.edu/about/reporting-concerns-and-misconduct/.
Computing Equipment
We recommend you have a personal laptop consistent with CAEN recommendations.
Test your internet connection with the U-M Custom Speedtest website and make sure it meets the minimum requirements for any UM service. You'll need more bandwidth if there will be multiple simultaneous users in your household.
Resources for help with computing equipment:
- ITS Sites @ Home (long-term laptop loan program)
- ITS Tech Help (technical support, repair services, short-term laptop loans)
You may also use computer workstations in CAEN labs on campus or connect remotely.
Curriculum
As the course title suggests, we cover two deeply interconnected topics:
- Advanced Programming:
Building on prior programming experience, we cover advanced programming techniques to complete students essential toolkit. Topics include polymorphism, composition, metaprogramming, exception safety, resource management, and concurrent programming. - Principles of Software Design:
We explore fundamental principles of effective software design, including a particular focus on developing effective abstractions and managing the connections and coupling between them, from which other principles, practices, and patterns can be derived and critiqued.
Learning Outcomes
During/after the course, students will be able to...
- ...apply advanced programming techniques to authentic, complex software problems.
- ...develop fundamental reasoning skills for analyzing/writing concurrent software.
- ...appreciate the tradeoffs involved in various approaches to software design.
- ...write more robust, flexible, and maintainable code.
- ...evaluate and explain software quality according to fundamental principles.
- ...identify and implement improvements to poor or overly-complex codebases.
- ...recognize when (and when not) to use established heuristics and design patterns.
- ...engage in continuous improvement and collaborative professionalism in software design.
Textbook
The course does not require or recommend any particular text. There is no well-recognized, authoritative resource for software design principles. We recommend thoughtful engagement and critique of published works in the area, which tend to vary dramatically in quality.
Technical reference materials such as the Typescript Handbook or documentation for various libraries and frameworks are freely available online.
Prerequisites
Coursework
EECS 281 with a minimum grade of "C". Contact the CSE Undergraduate Advising Office for questions.
Skills
Sufficient programming fluency - the course focuses on advanced techniques and software design principles, and our approach and pacing presumes you're already proficient in reading and writing code. If you earnestly engaged in projects in previous courses and found them approachable, you've got what you need. If you've used AI coding tools for a significant portion of previous coursework, you'll likely get less out of this course.
Exams
There will be one midterm exam and one final exam, administered in-person, on-paper, at a scheduled time. Exam dates are posted in the schedule on eecs498-software-design.org.
Alternate Exams
We may provide alternate exam times for students with a valid, documented conflict with a required activity in another course or official university-affiliated activity, or to help students avoid negative academic consequences when their religious obligations conflict with academic requirements.
We also provide alternate exams in cases of unanticipated medical or personal emergencies.
All requests for alternate exams must be submitted through the administrative form linked on the course website.
Labs
Lab sessions are 110 minutes, starting at the scheduled time. Labs involve a mix of pragmatic tutorials, coding practice, and group software design exercises. Make sure to bring a suitable laptop or tablet to lab.
Attendance, participation, and completion of lab exercises is verified by course staff and recorded for credit. (See our grading policies section for information on lab drops.)
During some labs, you'll meet briefly with a staff member for a project feature demo, worth credit toward your project grade.
You may leave early if you have completed all lab exercises and the project feature demo.
Projects
The course projects involve the incremental development of a single, large-scale codebase for a non-trivial software system. We'll share information in lecture, lab, and project specifications about the system you're building.
Project Groups
The initial implementation phase of project 1 is completed individually. The remaining projects (including the revision phase of project 1) are completed in a consistent group of 3 throughout the rest of the term.
There are three options for project 1, which correspond to three required components of the codebase for following projects. Students may choose their own groups, but it is to your advantage to plan to work with others who are not implementing the same project 1 option (otherwise, you'll need to implement the missing ones when you combine).
Be conscientious about choosing your project group. Before committing to a project group, please discuss your expectations, work habits, and communication preferences with your potential group members. If you don't align on these points, or you have other concerns, you should seek others to work with. Not everyone is a great fit together, and that's okay. If you are not able to find an effective group, please reach out to the course faculty or staff.
All group members are expected to earnestly contribute to the project and communicate effectively throughout the term. We recommend you collaborate closely on project design and implementation, especially since these are components on which you will be graded together. Please reach out to faculty if you have questions or concerns about group dynamics.
Project Structure and Deadlines
There are several components in the lifecycle of each project.
-
Phase 1: Initial Writing (two weeks)
A project specification outlines additional features you'll need to add by implementing programming techniques and design patterns covered in the course. You'll sometimes need change your approach and/or significantly refactor your existing code.
There are two deliverables for this phase:- Feature Demo: Completed in-person in Friday Labs on the due date.
- Project Deliverables: Submitted via GitHub by 11:59pm Friday on the due date.
-
Initial Review (one week)
Course staff review your codebase by hand for design and best practices, especially according the most relevant topics covered in lecture and lab and that are emphasized in the current project. We'll grade your design and implementation according to a rubric and provide detailed feedback and suggestions for improvement. Initial grading is more lenient. We'll get this back to you within one week of initial submission. -
Phase 2: Revision (two weeks)
You'll have the opportunity to revise your design and implementation based on our feedback. The timeline for these revisions overlaps with work on implementing the next projects and your codebase may have evolved significantly. That's fine - focus on addressing the underlying design issues and suggestions in the staff feedback.
There is one deliverable for this phase:- Project Revisions: Submitted via GitHub by 11:59pm Friday on the due date.
-
Final Grading (one week)
Course staff review and grade your codebase again using the same rubric as in the first phase. This time, grading is more strict. We'll also provide additional feedback and suggestions, which may be helpful for future projects as your codebase continues to evolve.
The diagram below shows the cadence of projects throughout the term. All deadlines are on Fridays.
Here's an example walkthrough of the project 2 timeline:
- Project 2 is released after the initial project 1 deadline. Your group works on initial implementation of project 2 in weeks 4 and 5. It's due on Friday, Feb 6, with the feature demo in lab and deliverables submitted via GitHub by 11:59pm.
- The staff review your initial deliverables and provide a grade and feedback within one week, by Friday, Feb 13. Then you have 2 weeks to revise your codebase accordingly. In the case of project 2, the intervening midterm and spring break weeks don't count, so final revisions are due Friday, Mar 13.
- You'll want to be thoughtful about interleaving work on the projects where they overlap. The revisions phase for project 2 overlaps with the implementation phases of projects 3 and 4. You might choose to incorporate some revisions right away or put others on the backburner.
Project Repositories and Submission
We'll provision GitHub repositories for each group with some initial configurations and two initial branches: main and dev. Use dev for the primary branch as you're working on each project. You're welcome to create additional feature branches or use any other git workflow that suits your team. To submit either project deliverables or project revisions, make a pull request from dev to main before the deadline, tag the staff, and merge into main. The pull request and associated commit should reflect the current state of your codebase and changes from the previous submission.
For project revisions - it's fine if your codebase contains unfinished features from an overlapping implementation phase for a subsequent project. In fact, the code doesn't necessarily need to be in a runnable state, as long as it's not a total mess and we can still assess the relevant design and implementation portions.
Project Grading and Feedback
Except in exceptional circumstances, each student in a project group will receive the same project grades.
Project Feature Demo
(3% course grade)
Upon completing the initial writing phase of each project, you meet with staff briefly (~5 minutes) to demo feature completion in lab. The project specification will provide guidance on what is expected for each project's demo.
Initial Review and Final Grading
(3% + 3% course grade)
The course faculty and staff will review student codebases (i.e. the state of the codebase represented in your submission pull request) and grade them according to a rubric. The rubric is specific to each project and the relevant programming techniques and design principles covered in the course. Each rubric item is evaluated on a 3 point scale:
- 0 - Missing (Related portions are not complete enough to meaningfully evaluate this item.)
- 1 - Insufficient (Significant issues or shortcomings.)
- 2 - Growth Needed (Adequate, but clear areas for improvement.)
- 3 - Exemplary (Implements relevant techniques and principles with few or no issues.)
Our intent is that the initial review and final grading for each project will use the same rubric and each individual item is generally graded with the same rigor, but the points needed for full credit are different. For example, assume a rubric has 10 items for 30 points total. On the initial review, your score might be computed out of 24 points, whereas on the final grading your score might be computed out of 30 points. (Because this is the first offering of the course, we will need to calibrate the exact numbers as we go.)
Note that your score for a rubric item on the initial review indicates an evaluation at that point in time, but does not necessarily guarantee a commensurate evaluation on the final review - since your codebase is evolving, you might need to pay close attention to a particular area to maintain a high quality of design and implementation. We'll do our best to give helpful feedback on particular areas to watch for.
Grades
Letter grades are assigned on a straight scale according to your weighted overall score across all assignments.
Assignment Weighting
We calculate your total weighted score using these weights.
| Assignment | Weight |
|---|---|
| Lecture | 5% |
| Lab | 5% |
| Projects (9% each, details) | 45% |
| Midterm Exam | 22% |
| Final Exam | 22% |
| Entry and Exit Surveys | 1% |
| Total | 100% |
Grading Policies
Lecture Attendance
Each lecture is worth equal weight. You may miss up to 4 lectures and still earn full credit.
Lab Absence
We drop the lowest 2 labs for each student. If you must miss more than 2 labs due to e.g. a planned medical procedure, unanticipated emergency, or official university conflict, you may submit at administrative request for an excused absence. Please provide documentation of the extenuating circumstances.
Project Feature Demos
Ensure that at least one (ideally all) of your group members are present at lab to complete and receive credit for project feature demos.
Curving
We may curve exams individually, for example, if an exam is significantly more difficult than planned. We may curve or otherwise adjust project scores, for example, if it turns out the point distribution in our rubric is miscalibrated or has insufficient resolution. Generally speaking, we won't "curve down" on anything.
Minimum Pass Thresholds
To pass the course with a C or better, your total weighted project score must meet a certain threshold, and your total weighted exam score must meet a certain threshold. Otherwise, the maximum grade you may earn is a C-. The precise thresholds are to be determined. The policy is to ensure sufficient mastery of course material as measured in both contexts (and will only affect students with vastly different scores on projects vs. exams).
Grade Adjustments
Since this is the first offering of the course, curving policies or other grade adjustments are yet to be determined. Our goal is that grades in this course will be distributed in a way that authentically represents mastery of learning objectives and that is generally consistent with other upper-level computer science electives. We also recognize that population of students taking the inagural offering of a course may involve self-selection effects and are not committed to a grade distribution of any particular shape.
Exact, final grading policies will be determined after the midterm exam and posted well in advance of the course withdraw deadline.
Letter Grades
After computing the total weighted score and considering the minimum pass thresholds, we use these ranges to assign letter grades. Each range is half-inclusive, for example a score of 89.999% is a B+ and a score of 90.0% is an A-.
We do not curve the course overall or otherwise adjust letter grade thresholds.
| Total weighted score | Letter grade | |
|---|---|---|
| 0 - 50% | E | |
| 50 - 60% | D | |
| 60 - 70% | C- | |
| 70 - 77% | C | Must Meet Minimum Pass Thresholds |
| 77 - 80% | C+ | |
| 80 - 83% | B- | |
| 83 - 87% | B | |
| 87 - 90% | B+ | |
| 90 - 93% | A- | |
| 93 - 97% | A | |
| 97 - 100% | A+ |
Extensions and Exceptions
We do not regularly accept late work. Project submissions are not allowed past the published deadline, except in the circumstances outlined below.
Planned Exceptions. We will consider extension requests made at least two weeks in advance, for example, for religious holidays or planned medical procedures.
Emergencies. If you experience a medical or personal emergency, please reach out to us! We will consider exceptions on a case-by-case basis. Please provide documentation of the emergency. Requests must be made at least 24 hours before the assignment deadline, unless the emergency prevents prompt communication to course faculty or staff.
Submit extension/exception requests via the administrative request form at eecs498-software-design.org.
Regrades
Exams are graded by hand. We will provide an opportunity to request a regrade to correct grading errors. We will regrade the entire question and fix any mistakes (your score may go up or down).
Scores for lecture, lab, and projects are posted on Canvas. Please report any clerical errors.
Projects are graded by hand. We understand that grading software design is nuanced and potentially subjective. Other than clerical errors or egregious mistakes, the subjective determination of the faculty and staff are considered final.
In all cases regrade requests are due no later than 7 days after a grade is released unless a shorter deadline is specified.
Academic Integrity
All work you submit must be your own. Your work may not be derived from someone else's either in whole or in any significant part.
All students are expected to earnestly contribute in their project groups and are responsible for academic integrity.
We feel collaborative learning is important. We encourage students to review others' work in a live format (in-person or virtually) to provide assistance or improve their understanding. Do not do others' work for them.
Do NOT share a copy of your code with others or ask for someone else's code. Do NOT provide others access to your project repository.
Do NOT make your project code available in any form. You are still responsible for following these rules even after finishing the course.
If you are unsure about an issue relating to academic integrity, please contact the course staff with questions.
AI Policy
The use of AI tools is not considered an honor code violation, but we recommend caution and discretion. Any use of AI tools to write project code must be documented in submission pull requests so that the staff are informed and can provide effective feedback.
AI-Assisted Autocomplete
Writing most of the code yourself is helpful for developing fluency in Typescript and making sure you think through the code you're writing, line-by-line. This is particularly true in the early phases of the course. You should generally only use AI tools for things you already know how to do (or things you don't care to learn or need to understand). As the course progresses, make an informed decision about tools for AI-assisted autocomplete (e.g. Copilot).
Agentic Coding Tools
We recommend you avoid using agentic coding tools at all (i.e. you write a prompt and the AI writes large portions of code or proposes substantial changes to your codebase). Doing the work yourself to write code using advanced programming techniques and software design patterns is an essential part of the learning process. Agentic tools make it too easy to miss that at this point.
Using AI for Learning
AI tools can be useful for interactively engaging with course material or examples. In each case, be responsible and vigilant! Discern whether the AI tool is short-circuiting the challenging, yet essential learning process or whether it is enabling you to engage more, ask questions, and really dig into the maaterial. Find a way to test and verify your own understanding. A good heuristic - if an AI tool enables you to learn "faster", it may be that the efficiency gains are simply that you're learning less in less time.
Other Contexts
The use of generative AI in a deceptive or malicious fashion is prohibited. This includes but is not limited to:
- Impersonating yourself or others in course contexts, for example in emails, virtual office hours, or online course forums.
- Passing off generated content as your own work when contributing to group assignments. Be open with your group members.
- Using generative AI to facilitate harassment of others.
Honor Council Process
We report suspected violations to the Engineering Honor Council. The Honor Council determines whether a violation of academic standards has occurred, as well as any sanctions. It your responsibility to understand the Honor Code.
Here's what you can expect if you are reported for an Honor Code violation:
- The course instructors submit an official report to the Honor Council.
- The Honor Council notifies you of the report, and explains the next steps of the process. You receive a copy of the report, including the evidence of the suspected violation.
- The course instructors play no role in adjudicating reported cases.
- The Honor Council notifies course instructors when your case is resolved. Any penalties they prescribe are applied to your grade. If you are found not responsible, your grade is unaffected.
If you have a pending honor council case at the end of the term, you receive an "I" (incomplete) grade until the case is resolved. We will send you a grade projection via email to help with planning. Your grade is updated once the case is resolved. The "I" should not remain on your transcript.
Course Policies
Commitment to Equal Opportunity
As indicated in the General Standards of Conduct for Engineering Students, we are committed to a policy of equal opportunity for all persons and do not discriminate on the basis of race, color, national origin, age, marital status, sex, sexual orientation, gender identity, gender expression, disability, religion, height, weight, or veteran status.
Resources for Student Support
The CSE department maintains a listing of resources for student support, including University and College of Engineering resources as well as student organizations.
Students' Health and Well-being
If you or someone you know is feeling overwhelmed, depressed, and/or in need of support, resources are available via University Health & Counseling at https://uhc.umich.edu. All counseling services and most medical services are free for students. You may reach out to Counseling and Psychological Services (CAPS) at (734) 764-8312, including a 24/7 after-hours support line for urgent mental health concerns. If you or someone you know is experiencing an emergency, call 911 or go directly to the nearest hospital emergency department. You can also call or text the national suicide and crisis lifeline at 988.
Accommodations for Students with Disabilities
We believe all students deserve access to a high-quality, equitable academic experience. Resources and accommodations for students with disabilities are coordinated by Student Accessibility and Accommodation Services (SAAS). If you think you may need accommodations, it is critical to reach out to the Services for Students with Disabilities (SSD) Office as soon as possible so that they can work with you to identify and document appropriate accommodations, and so that instructors are able to work with you to implement them. Any information you provide is treated confidentially.
Recordings
Course lectures may be audio/video recorded and made available to other students in this course. As part of your participation in this course, you may be recorded. If you do not wish to be recorded, please contact your instructor the first week of class to discuss alternative arrangements.
Students may not record or distribute any class activity without written permission from the instructor, except as necessary as part of approved accommodations for students with disabilities. Any approved recordings may only be used for the student's own private use.
Research Disclosure
Your class work might be used for research purposes. No identifying information about you or your work will be published. For example, we may use anonymized student assignments for computing education research. Or we might survey responses to help us improve the course and better understand instructional techniques. Any student who wishes to opt out can contact the course staff (eecs498-software-design@umich.edu) at any time up to seven days after final grades have been issued. This has no impact on your grade in any manner.