Meeting Time

• Tuesday 3:30-4:45pm in Gross Hall room 107
• Thursday 3:30-6:30pm in Gross Hall room 107

For online meetings, Zoom call information will be posted on Sakai 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.

Teaching Team

	Professor Robert C. Duvall LSRC room D228 Office Hours via Zoom: Tuesdays 2-3pm, Wednesdays 2-3pm Drop-in policy: You may make an appointment via email	Undergraduate TAs Ellie Angle Samy Boutouis Kathleen Chen Will Convertino Bill Guo Billy Luqiu Donghan Park Joshua Petitma Saurav Sanjay Ryan Weeratunga Alicia Wu Kevin Yang
	Graduate TA Bohan Li Office Hours via Zoom: Mondays 12-1pm, Thursdays 1-2pm Drop-in policy: You may make an appointment via email

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 Q&A 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.

Books

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 lecture for you to ask questions about the reading but the majority of class time will be an extension of the reading, not a summary.

Java Programming

Core Java by Cay Horstmann and Gary Cornell Effective Java by Joshua Bloch Modern Java in Action by Raoul-Gabriel Urma, Mario Fusco, and Alan Mycroft

Program Design

Clean Code by Robert Martin (supplemented with video lessons) The Pragmatic Programmer by Andrew Hunt and David Thomas Design Patterns Explained by Alan Shalloway and James R. Trott

Teamwork and Project Management

Teamwork Is An Individual Skill by Christopher Avery, Meri Walker, Erin O'Toole Murphy What Got You Here Won’t Get You There by Marshall Goldsmith and Mark Reiter The Agile Samurai by Jonathan Rasmusson

Other Interesting Software Design Books

A Philosophy of Software Design by John Ousterhout Pattern Hatching - Design Patterns Applied by John Vlissides The Design of Design by Frederick Brooks

Habits

Atomic Habits by James Clear Hello Habits by Fumio Sasaki Clean Coder: A Code of Conduct for Professional Programmers by Robert Martin

Generally Useful Books

The Unspoken Rules by Gorick Ng Joy of Search by Daniel Russell Trampled by Unicorns by Maelle Gavet

Topics

The following topics will be covered during the semester.

• Program Design: Interfaces, Principles, Patterns, APIs, Architectures, Frameworks
• Working in Teams: Agile Processes focusing on Communication and Cooperation
• Tools: Version Control, Debugging, Build tools like Maven, Unit Testing
• Java Programming: Inheritance and Polymorphism, Exceptions, Reflection, Lambdas, Generics
• Professional Practices: Classpath resources, Packages, Third-party libraries, Code reviews

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.

Grading

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?  balanced between a general "design checklist" and project specific design criteria
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.

Final Project

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, Q&A 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)

No Late Submissions

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.

Collaboration Policy

In accordance with the Duke Community Standard, we encourage proper collaboration, in which all parties equally participate, on programming projects and class work. Individual work (journals) must be your own work and turning in code that you cannot explain is considered cheating.

Specifically, it is unacceptable to

• let someone copy your program code
• copy code from a previous solution of an assignment
• search on the Internet for direct answers to the primary design problems posed by the assignments

You may use small pieces of properly attributed code (using inline comments or in your README if more appropriate) from online sources or open source projects as long as that code

• does not solve a significant design problem in the assignment
• is understandable and agreed to by the people in your team
• is reasonably designed and implemented (you are responsible for any code you add to the repository and cannot claim that design defects are "okay" because you did not write it)

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.

If you are not sure what the collaboration policy is for a given assignment, please ask!

Diversity

This course is committed to Duke's Commitment to Diversity and Inclusion. Moreover, beyond the diversity listed in this statement, we believe this class should be inclusive to all students such that they feel the class is a secure and supportive learning environment.

Disabilities

This course is committed to providing equal access to students with documented disabilities. Students 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.

Computing Requirements

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).

Online Course Information

Web Site (http://www.cs.duke.edu/courses/spring22/compsci308/). Many of the materials for this course, including the syllabus, class notes, reading assignments, homeworks, and other resources, will be available through this course web site.

Email. Please check your email regularly, as important course announcements may be sent via email.