|Advanced Software Design and Implementation
An expert is someone who, over many years, manages to remain confident enough to keep trying and humble enough to keep learning. — James Clear
For Hybrid meetings, Zoom call information will be posted on Canvas and Ed to protect course security.
Attendance is required (either in person or online) as class time will often involve participatory exercises, code reviews, or team meetings. The combined lecture and discussion section meeting will be used for team meetings or to practice concepts in a controlled setting to help you learn how to apply them in your team projects.
You will be expected to do a significant amount of reading, coding, and debugging outside of class time.
We are excited to bring you the best learning experience we can collaboratively — we will try to adjust how the course works in response to feedback from students, UTAs, and those who are helping deliver course content at Duke.
Professor Robert C. Duvall
- LSRC room D228
- Office Hours: Tuesdays and Wednesdays 2-3pm in my office
- Drop-in policy: You may make an appointment via email
- David Bian
- Vincent Chen
- Alexis Cruz-Ayala
- Delali Cudjoe
- Ian Flynn
- Ethan Horowitz
- Ritvik Janamsetty
- Aryan Poonacha
- Han Zhang
Instructor Luke Moffett
Email is the best way to contact the Teaching Team if you have a personal concern. When using email, please put CompSci 308 at the start of your subject line to help ensure that your email gets past our spam filters and is delivered correctly. If you send us an email and do not get a response within 24 hours, we probably did not receive it. In general, you should only email us about administrative aspects of the course; questions about course content are better made using the course Bulletin Board since more people will see it.
Our goal is simple: to help you learn — both inside and outside the classroom. If you have a problem or question, we want to talk about it — do not put it off.
Most of the readings assigned during the semester will be excerpts from books or online articles. However, many students also like to use a reference book about advanced programming topics, so the books listed below are optional. We have curated a lot of information, but the books below are more complete in their coverage.
You are expected to do the readings in order to be prepared to ask and answer questions in class. Time will be given at the beginning of class for you to ask questions about the reading but the majority of class time will be an extension of the reading, not a summary.
- A Philosophy of Software Design by John Ousterhout
- Pattern Hatching - Design Patterns Applied by John Vlissides
- The Design of Design by Frederick Brooks
- Clean Coder: A Code of Conduct for Professional Programmers by Robert Martin
- Atomic Habits by James Clear
- Hello Habits by Fumio Sasaki
The following topics will be covered during the semester.
The exact order and details of these topics will be given on the course Calendar, which is subject to change during the semester based on the pace needed. Additionally, we may explore collateral topics as dictated by class interests.
This course is about the creation of software in teams. Thus it is much more than simply a programming course. To receive a passing grade, you must demonstrate that you have completed significant programming and been a successful part of a team. This emphasis is reflected in the grading weights below that give equal consideration to the programming assignments and “soft-skills” needed to survive as a software developer.
30% Skills: consistent improvement in coding, designing, and project planning and management 20% Engagement: consistent participation in team deliverables and activities and consistent commits using GIT 30% Design: well thought out and justified design implemented with readable, principled, code 20% Functionality: significant features implemented following an overall design plan
Project Weights. The grading for this course is more like a humanities course than a standard CompSci course because we are not simply testing whether a program works or not when grading software design. We are attempting to determine how much thought went into your project. Thus grades are determined by a combination of the following general categories (as well as project specific design criteria):
30% Design: how well designed is the project? 20% Craftsmanship: how clean and readable is the code? 20% Quality: how robust and well tested is the project? 15% Completeness: how well does the project work? 15% Documentation: how well is the code documented and the design justified?
Design Counts. Note that your program's functionality counts among the least percentages. This implies that a solid, working sub-set of the complete program, with a design that clearly supports easily adding the remaining functionality, will receive a higher grade than a completely functional program hacked together at the last minute and not obviously tested. Unlike in other Computer Science courses where the program's functionality is primary, this course focuses on program design. The project requirements are usually chosen to highlight a specific set of design ideas. Simply implementing all of the requirements without evidence you have thought about how to they are integrated into a complete design will result in a low overall grade. On the other hand, small bugs in some requirements will be tolerated if they are documented and the design is well done. This notice constitutes fair warning of the consequences to your grade of poorly written code.
Teamwork Counts. One summary grade will be given for the functionality of each programming project. Thus your individual grade depends not only on your programming skills but on your ability to work with others. More credit will be given to programs that have minimal, but collaborative, functionality than to projects that have one piece working perfectly, but do not represent the integrated efforts of the team. In addition to the final submission, each student must submit an individual project analysis after submitting the final version of the project. This analysis does not affect the team grade, but is weighted equally as an individual grade. For example, if the team project fails, despite your best efforts, but you write a good, concrete, and detailed analysis of why it failed you may receive a D on the project, but an A on the analysis. This notice constitutes fair warning of the consequences to your grade of not being a reliable and respectful team mate.
Peer Evaluation Counts. Teams will be chosen for you based solely on schedule compatibility. This means that your team may not be an ideal mix of compatible personalities. As a team, it is your responsibility to identify problems as soon as possible and still plan to deliver a working program. You will be asked to assess yourself and your fellow student's participation in the team in such a way that it factors into their final grade. This notice constitutes fair warning of the consequences to your grade of not helping to make your team project a success.
Just Effort Does Not Count. I do not give grades: students earn their grades. It is your responsibility to earn the grade you desire. In general, to earn an A on any assignment you must go beyond what is expected. Simply meeting all requirements is worth only a B+. Meeting all requirements superbly can earn an A-. Doing more than is required, or doing astonishingly good work, is the only way to earn an A. Graded items will be scored through regular meetings with the Teaching Team who are looking for a record of sustained improvement based on feedback that demonstrates comprehension of the goals of software design. This notice constitutes fair warning that you must demonstrate evidence of consistently making significant contributions and improvements to receive a passing grade.
The last month of the semester will be spent creating a larger software project built with APIs that are refined and extended through multiple draft releases. This project is the focus of the course and is given in lieu of a final exam and must be completed and submitted before the course's scheduled exam time.
Practice Counts. The percentages given below reflect each project's relative weight in the course. In other words, the projects leading up to the final project are like practice before the main event: a necessary place to learn from your mistakes before they really count.
25% Individual work (first project, journals, Bulletin board posts, and code committed to team projects) 25% Small team projects (in preparation for the final project) 50% Final team project (focus of the course's second half)
All Projects Must Be Submitted On Time. This may seem overly harsh, but it is important that you do not get behind in this course — its pace is too fast and getting behind even a few days can be hard to recover from since, like a domino effect, each tardiness tends to propagate through the following assignments. Additionally, it allows us to give you feedback as quickly as possible. It is not possible to cram or skim in this course; the secret to successfully surviving this course is to start early and work steadily.
Prioritize Your Effort. If, for some reason, you (or your team) cannot meet a specific deadline ,submit your best effort by the deadline by choosing judiciously what you can finish that is designed well. Afterwards, you will be given the chance to write a detailed project analysis, including what you would have done if you had more time. Making significant contributions to a project after the deadline is considered cheating and will result in a loss of that project's grade.
Be Proactive. Individual extensions will be granted only for university recognized reasons (see the Class Attendance and Missed Work Policy) or other circumstances beyond your control presented with a Dean's excuse. However, you are responsible for recognizing any such concerns well before a due date because extensions will not be granted within 12 hours of a deadline. If you are having trouble, be sure to see one of the Teaching Team as soon as possible. Do not give up, ask for help.
Despite the stereotypes, computer scientists almost never work alone. The reality is that significant real-world projects in computer science are almost always pursued by teams. Effective collaboration and improved teamwork are a focus of the course. Thus, in accordance with the Duke Community Standard, we encourage proper collaboration, in which all parties participate collaboratively, on programming projects and class work.
Specifically, it is unacceptable to
You may use small pieces of properly attributed code (using inline comments or in your README if more appropriate) from online sources, open source projects, or generated by AI as long as that code
You may consult with the Teaching Team about any aspect of the course. Consulting with other students in a general way, e.g., about debugging, programming concepts, or questions about wording on the assignment is always encouraged but you may not actively work with someone else not on your project team.
Consult means you can discuss programs in a general way before writing code and get help with debugging your program, but you must write your own code and do your own thinking about the problem. For each assignment you are expected to include a list of the people with whom you have consulted (including any other students and the Teaching Team) in the README file you submit with the assignment. You should also cite any resources other than class materials you use (e.g. web pages, notes from other courses at other universities, etc.). This file is required and failure to provide it will result in rejection of the assignment as complete.
Individual work (journals) must be your own work and turning in code that you cannot explain is considered cheating. If you are not sure what the collaboration policy is for a given assignment, please ask!
This course is committed to Duke's Commitment to Diversity and Inclusion.
Even beyond this statement, we believe this class should be a secure and supportive learning environment for all students.
This course is committed to providing equal access to students with documented disabilities. Anyone with disabilities may contact the Student Disability Access Office (SDAO) to ensure equitable access to this course. There you can engage in a confidential conversation about the process for requesting reasonable accommodations both in the classroom and in clinical settings.
Please note that accommodations cannot be provided retroactively — seek out extra assistance and advice early.
The semester can be long and stressful for many students, so taking steps to reduce stress and improve your physical health are important to maintain positive mental health.
Duke's goal is simple: to help you learn, both inside and outside the classroom. If you have a problem or question, we want to talk about it — do not put it off.
You are expected to have access to and on-going use of a computer on which you can install the software used in the course. A laptop is strongly recommended (so you can bring it to class and team meetings or with the Teaching Team).
pushing your code to the course Gitlab server.