CS 3100: Program Design and Implementation II

Prerequisites: CS 2100 or equivalent

Credits: 4 credit hours

Course Description​

Building on foundations introduced in CS 2100, examines program design at increasing scales of complexity. Reviews abstraction, encapsulation, inheritance, and interfaces in statically-typed object-oriented languages. Presents a comparative approach to software design patterns and paradigms, including object-oriented and functional programming. Fosters a deeper understanding of the principles of program design, including interface design, test-driven development, graphical design notations, reusable software components, and open-source ecosystems. Illustrates the impact of design-time decisions on software correctness, including accessibility, changeability, performance, reusability and privacy. Students collaborate throughout the semester to design and implement a large software project.

Course Objectives​

Upon successful completion of this course, students will be able to:

• Analyze software requirements and synthesize an object-oriented design utilizing open-source libraries
• Identify the stakeholders of a software module, along with their values and interests
• Utilize the vocabulary of design patterns to compare the impact of design decisions on non-functional requirements such as accessibility, changeability, performance, reusability and privacy
• Given a software module, identify its potential failure modes, the impact of those potential failures for all stakeholders, and propose modifications to the software design to mitigate those risks
• Design and implement an effective test suite for a piece of software
• Implement a software project in the Java programming language
• Work with another student on programming and design activities

Course Structure​

The course consists of lectures, labs, assignments, and a semester-long project. The Schedule page contains the specific dates and topics for each lecture and lab. Loosely, the course is organized as follows:

• Module 1 (weeks 1 - 5): Design principles and patterns, Java fundamentals
• Module 2 (weeks 6 - 11): Development practices and user-centered design
• Module 3 (weeks 12 - 15): Design in the large: architecture and distributed systems

Module 1 and 2 are followed by exams, and Module 3 is followed by a cumulative final exam.

Students complete individual programming assignments that build into a larger project, Cook Your Books. Students will practice design skills by both writing new code and reviewing existing code. Assignments are structured such that, each week, students implement the week's requirements using the solution from the previous week as a starting point. Students complete a self-reflection on each assignment, examining the design decisions they made and the tradeoffs they considered. Early assignments will have students work individually to implement a small feature in the codebase. Later, students will form teams to work on a signficiantly larger feature in the same codebase.

Grading​

The course uses a total points system. Your final grade is based on the percentage of points earned out of 1000 total points.

Assignment Point Distribution​

Individual Assignments:

Group Assignments:

Group Assignment Grading: Group assignments are graded as a team, but each team member must demonstrate minimum weekly contributions to receive the team's full score. Each week during a group assignment, you are expected to:

• Make meaningful code contributions (commits, pull requests) to the team repository
• Participate in team meetings and communication
• Complete your assigned tasks as agreed upon by the team

Your individual score on a group assignment is calculated as:

Your Score = Team Score × Contribution Multiplier

The contribution multiplier is informed by three sources:

1. Team collaboration surveys: Each week, every team member completes a brief survey reflecting on their own and their teammates' contributions.
2. Team mentor reports: Each team is assigned a mentor (a course staff member) who helps resolve interpersonal conflicts and provides observations on team dynamics.
3. Version control artifacts: Commit history, pull requests, code reviews, and issue activity in your team's repository provide objective evidence of contributions.

The contribution multiplier is 100% if you meet the minimum weekly contribution requirements, and may be reduced if you fall short. In cases of significant under-contribution, students may receive a substantially lower score than their teammates—or zero credit—regardless of the team's overall performance.

This policy ensures that every team member actively participates and that no student can earn credit by relying on their teammates' work. If you are struggling to contribute due to circumstances beyond your control, communicate with your team and the course staff as early as possible.

Letter Grade Requirements​

Your letter grade is determined by both your total points AND meeting minimum thresholds in key categories. You must satisfy all requirements for a grade level to earn that grade.

Plus/Minus Grades: Once you meet the thresholds for a letter grade, your +/- modifier is determined by where your total points fall within that range:

There is no A+ grade. If you fail to meet the thresholds for a letter grade, your grade is capped at the highest level whose thresholds you satisfy.

Why thresholds? These requirements ensure that you demonstrate competence across different aspects of the course. You cannot compensate for missing fundamental skills (tested in assignments) by only performing well on exams, or vice versa. The exam threshold for a B (55%) is intentionally lower to accommodate students who struggle with timed assessments but demonstrate mastery through their project work.

Grade Recovery Policies​

Final Exam Replacement: If your final exam score is greater than the average of your two midterm exam scores, your final exam score will replace that average. This allows you to recover from poor early exam performance by demonstrating mastery on the comprehensive final.

Late Work: You start the semester with four "Late Tokens" that grant a 24-hour extension on any assignment. You can apply one late token per assignment, but you must apply it before the original due date. No assignments will be accepted after the due date (or after the extended due date if a late token was applied). For exceptional circumstances, contact your instructor. See Pawtograder Documentation for details.

Labs and Participation​

Labs (50 points): Labs are graded on the "good faith effort" standard: if you attend your lab section and make a submission that demonstrates your effort to complete the lab, you will receive full marks for it. There are 14 labs; each is worth approximately 3.5 points, with the total capped at 50 points (allowing you to miss a few without penalty).

Class Participation (50 points): Participation is assessed through in-class activities, including polls, discussions, and short exercises. Regular attendance and engagement is expected. Each instructor will provide details on how participation points are earned in the first week of class. Completing online participation activities in violation of instructors' rules (such as completing polls remotely without prior written permission) constitutes an academc integrity violation and will result in losing all participation points for the semester.

Detailed rubrics will be published with each assignment.

Grading grievances: If you have concerns regarding the grading of your work, please let us know right away by opening a regrade request in Pawtograder. All regrade requests must be submitted within 7 days from your receipt of the graded work. If your regrade request is closed and you feel that the response was not satisfactory, you may appeal to the instructor via Pawtograder within 3 days of the resolution of your regrade request by the grader.

Communication with the Course Staff and Peer Support​

Contacting your instructor​

Each instructor maintains their own office hours. You can also directly email your instructor, but please note that instructor responses may take up to 48 hours to receive a response.

TA Office Hours​

TA office hours are available throughout the week to provide one-on-one support with your coursework. To get help, join the queue through the Pawtograder office hours system—we operate on a first-come, first-served basis.

To make the most of your time:

• Come prepared with a specific question or issue. When you submit a help request, describe your concern so the TA can prepare.
• Have your code accessible (via GitHub or locally) so you can share your screen or walk through it together.
• If you need help debugging please follow our debugging workflow, as outlined in Lecture 14, and summarized in the syllabus below.
• Typical sessions last 10-15 minutes, so focus on one issue at a time.

What we can help with: Clarifying assignment requirements, debugging guidance (we'll help you find the bug, not fix it for you), design and architecture questions, testing strategies, tool usage (Git, IDE, autograder), and conceptual questions about course material.

What we can't do: Provide direct code solutions, pre-grade your work, or process extension requests (those go through a separate channel).

Coverage increases 48 hours before each assignment deadline, so expect more availability on Tuesdays through Thursdays of deadline weeks. If you encounter a common issue, we may direct you to a FAQ post that addresses it.

Debugging Workflow​

One of the objectives of this class is to provide students with experiences writing new code for large, existing codebases. We anticipate that you may run into difficulties debugging the project code: it is often difficult to build debugging skills until you have a problem in front of you that requires them. The course staff is happy to help you with debugging, with the specific goal of helping you learn to successfully apply scientific debugging.

Andreas Zeller’s Debugging Book provides an excellent guide to scientific debugging. The short version is roughly: if you can’t debug an issue in the first few minutes "just by looking at it", it will be hard to keep all of the relevant information in your head at once, and a formal process to help you generate and refine guesses for why something is wrong can be immensely useful.

The key idea is to create a debugging note file, where you track information like:

1. What was the input/application state that caused the bug?
2. What was the behavior that I expected?
3. What was the behavior that I observed?
4. What are possible hypotheses for that behavior?
5. How have I tested those hypotheses, and what was the result?

The overall goal with hypothesis formulation is to come up with possible causes for why the bug exists. Then, as long as those hypotheses are testable, we can prove or disprove them. Most hypotheses will be along the lines of "did I make an incorrect assumption about how a library or API works?" The devil is in enumerating all of the possible incorrect assumptions that you might have made, and testing them. The best way to attack these kinds of problems is to start with testing some high-level, general assumptions, and then refine them.

If you come to us for debugging help, we will ask you to answer these 5 questions, as our goal is to help you get better at debugging and not to simply point out bugs that we might have seen before. We are happy to discuss the problematic behavior that you are observing, possible hypotheses for why that behavior is occurring, and strategies to test those hypotheses. In the past, students have found that using a variety of strategies to test their hypotheses (e.g. using a debugger, creating a minimized test case, measured application of console.log statements, internet research) are useful, and we would be happy to demonstrate these. We may not be able to stay with you while you work on refining your hypotheses and fixing the bug, but would be happy to continue following up if you get stuck again. While it might be more satisfying to simply have us fix the bug for you, learning and practicing debugging strategies is essential as you move on to dealing with more complex and larger codebases.

Discussion Forum​

The Pawtograder discussion forum is your go-to resource for questions outside of office hours. Before posting, check the pinned FAQ post for your assignment or lab—many common questions are already answered there.

What to expect: You should receive a response from the course staff within 12 hours (often faster during peak times). However, other students may be able to quickly help answer your question. During the 48 hours before deadlines, the course staff will be monitoring the forums more frequently. Responses will guide you toward understanding, not provide direct answers. If your question is already in the FAQ, we'll point you there—and if it should be clearer, let us know.

Forum categories include:

• Assignments and Labs – specific Q&A (each has a pinned FAQ)
• AI Tools – questions about AI coding assistants, workshop recordings, and best practices
• Study Groups – find study partners
• #history-of-programming and #future-of-programming – explore broader topics in software engineering
• #memes – programming humor to brighten your day

The same boundaries apply as in office hours: we won't provide direct code solutions or pre-grade work. If your question is already in the FAQ, we'll point you there—and if it should be clearer, let us know.

In short: Office hours give you real-time, personalized help; the forums give you asynchronous support with a reliable turnaround. Use both! Check the FAQ first, come to office hours prepared, and you'll get the most out of your interactions with course staff.

Textbooks and Resources​

We do not recommend that you purchase any specific books for this class upfront. The course will refer to several texts, all of which are freely available online via Northeastern's library system.

Academic Integrity​

Computer science, both academically and professionally, is a collaborative discipline. In any collaboration, however, all parties are expected to make their own contributions and to generously credit the contributions of others. In our class, therefore, collaboration on assignments is encouraged, but you as an individual are responsible for understanding all submitted material in the assignment. Always strive to do your best, give generous credit to others, start early, and seek help early from both your professors and classmates.

Specifically:

• You are responsible for any material you turn in. The professor reserves the right to ask you to verbally explain the reasoning behind any answer or code that you turn in and to modify your grade based on your answers. It is vitally important that you turn in work that you understand.
• Copying material from another person is not allowed.
• Additionally, sharing solutions in forums (e.g., posting to public questions, posting code online, etc) constitutes an academic integrity violation, as it may make it harder for other students to do work on their own, harming their own learning. The course staff expend a tremendous amount of effort to provide you with high-quality assignments, and in turn expect that you respect this effort and do not share solutions.
• Collaboration is not allowed on exams. Any sharing or receiving information about the content of exams is an academic integrity violation, and may result in failing the class.

We strongly recommend that you write all code yourself. Even if you discuss solutions, or approaches, with others, do the actual typing on your own! And avoid playing games or trying to find loopholes -- i.e., do not merely type what someone says, or type what you see on anothers screen. While we do not consider collaboration a violation, we still encourage following these recommendations-- relying on others for your solutions may result in you not learning the material, and in this class, not learning the material will result in not being able to pass the exams. Even with perfect homework scores, failing to pass sufficient exam topics will result in a failing grade in the course, so take homework for what it is intended: extensive opportunity to practice the skills we are teaching, paired with high quality feedback about the solution you came up with.

The minimum penalty for an academic integrity violation is a zero on the assignment and a report to the Office of Student Conduct and Conflict Resolution (OSCCR). Penalties are increased if there are aggravating factors, such as stealing another student's work, or lying about cheating. Also, see the Official University Academic Integrity Policy.

If you have a question about what is considered a violation of this policy, please ask an instructor.

If you feel that cheating is your only option, please ask for help.

Artificial Intelligence​

Software Engineering in an Age of AI​

The hardest parts of building software have never been typing code. They are figuring out what a system should actually accomplish, negotiating conflicting stakeholder needs, making architectural tradeoffs that balance competing concerns like performance and maintainability, keeping a codebase healthy as requirements evolve, and coordinating effectively with other people. AI tools can produce syntactically correct code at impressive speed, but none of that addresses the engineering challenges that determine whether software succeeds or fails in the real world.

When AI generates a snippet of code, someone still has to decide whether it solves the right problem, whether it will integrate cleanly with the existing system, whether it handles edge cases appropriately, whether it introduces security vulnerabilities or performance bottlenecks, and whether future developers will be able to understand and modify it. These are all skills that have always been important in software engineering, but with the diffusion of AI, these skills have become even more important. This is precisely why our curriculum focuses so heavily on foundational engineering skills:

• Design for change (Lecture 7): Understanding coupling, cohesion, and information hiding—the principles that determine whether code can evolve gracefully or becomes brittle
• Requirements and stakeholder analysis (Lecture 9): Learning to discover what people actually need, navigate conflicting interests, and recognize hidden assumptions
• Testing and validation (Lecture 15): Developing the judgment to know what to test and why, not just how to write test syntax
• Teamwork and collaboration (Lecture 17): Practicing code review, documentation, and communication—skills that become more important, not less, as code generation accelerates
• Architecture and quality attributes (Lecture 19): Reasoning about tradeoffs among testability, performance, scalability, security, and maintainability
• Sustainability (Lecture 36): Understanding the long-term impacts of design decisions on the environment, economy, and society

When code can be produced faster, the bottleneck shifts to integration, validation, and maintenance. Evaluating whether generated code is correct, secure, performant, and aligned with your design goals requires deep understanding of what good code looks like—understanding that only comes from practice. Leveraging these insights, we introduce AI coding assistants mid-way through the course, providing you with the ability to quickly generate larger codebases, forcing you to face the challenges of integration, validation, and maintenance over the course of a single semester.

Why We Restrict AI Early in the Course​

AI coding assistants like Cursor, Windsurf, and Copilot are not permitted for the early assignments in this course. This restriction exists because we have not yet taught you to effectively review the code you could not have written yourself. Using AI assistance before developing foundational competence means accepting whatever the model produces without the ability to recognize errors, inefficiencies, or subtle misalignments with your actual requirements. The result is not learning with assistance—it is outsourcing the learning entirely.

Feeding assignment instructions to a model and receiving code or test cases in return bypasses the thinking that produces learning. "Only looking" at AI-generated solutions before writing your own undermines the process just as thoroughly—you end up pattern-matching against the AI's approach rather than developing your own problem-solving ability, and you never build the instincts needed to recognize when an AI solution is subtly wrong. LLMs become genuinely useful once you have the competence to break down a problem precisely, specify what you need, and critically evaluate the output. That competence is what you should have begun developing in CS 2100, and it is what we continue building in this course.

Our Approach: Competency Development, Not Just Restriction​

We do not treat AI as simply "forbidden." Each assignment indicates the expected level of AI usage, ranging from "Not allowed" through "Permitted" to "Required." These designations reflect the learning objectives for that assignment. Some assignments are designed to build foundational skills that require unassisted practice; others introduce AI as a tool to be used thoughtfully.

In Lecture 13, we cover how AI programming agents work and present a structured workflow for human-AI collaboration: identifying what context the AI needs, crafting effective prompts, evaluating outputs critically against your actual goals, calibrating toward desired outcomes, and documenting decisions. Lab 6 provides hands-on practice with these techniques.

Some interaction with AI is unavoidable—search engines now surface AI-generated summaries, and using models to clarify concepts is not necessarily problematic. But when you do use AI for information, you remain responsible for verifying accuracy against authoritative sources: official documentation, course materials, and course staff. Learning to read technical documentation is itself a valuable skill that pays dividends throughout a technical career.

The Economic Reality​

Software has historically exhibited Jevons' paradox: when a resource becomes cheaper to produce, total consumption increases rather than decreasing. Every major productivity improvement in software development—high-level languages, structured programming, automated testing, continuous integration—has resulted in more software being built, not fewer people employed to build it. There is no evidence that AI-assisted development will break this pattern. As certain tasks become faster, organizations pursue projects that were previously too expensive, creating new demand.

The skills that remain valuable are the ones AI does not provide: understanding what to build, designing systems that can evolve, validating that implementations meet requirements, and working effectively with other humans. These are skills that we emphasize in this course.

How Course Staff Use AI​

We maintain firsthand experience with these tools so we can guide you effectively. Some course materials were developed with AI assistance, and all such content has been reviewed and edited for accuracy. Examples include:

• Expanding learning objectives into draft lecture notes
• Drafting project requirements, instructions, solutions, test cases, and initial rubrics
• Developing Pawtograder, the course operations platform
• Creating visual assets like the OctoPaws logo and the eerie "Quality Without A Name" social badge
• Drafting this very policy document, synthesizing prior writings, emails, and notes that we have exchanged with each other

Using AI for these tasks allows us to focus on work that cannot be delegated: deciding what concepts to teach and in what sequence, designing assignments that build skills progressively, and providing feedback tailored to individual students. Every piece of AI-assisted content goes through the same critical review process we ask you to develop.

Inclusive Environment​

To create and preserve a classroom atmosphere that optimizes teaching and learning, all participants share a responsibility in creating a civil and non-disruptive forum for the discussion of ideas. Students are expected to conduct themselves at all times in a manner that does not disrupt teaching or learning. Your comments to others should be constructive and free from harassing statements. You are encouraged to disagree with other students and the instructor, but such disagreements need to respectful and be based upon facts and documentation (rather than prejudices and personalities). The instructor reserves the right to interrupt conversations that deviate from these expectations. Repeated unprofessional or disrespectful conduct may result in a lower grade or more severe consequences. Part of the learning process in this course is respectful engagement of ideas with others.

We believe that diversity and inclusiveness are essential to excellence in academic discourse and innovation. In this class, the perspective of people of all races, ethnicities, gender expressions and gender identities, religions, sexual orientations, disabilities, socioeconomic backgrounds, and nationalities will be respected and viewed as a resource and benefit throughout the semester. Suggestions to further diversify class materials and assignments are encouraged. If any course meetings conflict with your religious events, please do not hesitate to reach out to make alternative arrangements.

Name and Pronoun Usage​

As this course includes some discussion, it is vitally important for us to create an educational environment of inclusion and mutual respect. This includes the ability for all students to have their chosen gender pronoun(s) and chosen name affirmed. If the class roster does not align with your name and/or pronouns, please inform us of the necessary changes.

Accommodations​

If you have a documented disability, please register with Disability Access Services to get the accommodations that will help you succeed. Please do this even if you are unsure whether you will need accommodations, since there may be a delay if you decide you need them later. Please do not wait until it has seriously impacted your work, as accommodations are not retroactive. See additional information for Oakland students.

Policy on Recording​

Massachusetts and California laws prohibit students from recording classes without the consent of all participants, unless a disability accommodation is in place. We encourage you to seek accommodations to which you are legally entitled.

University Resources​

Title IX​

Title IX of the Education Amendments of 1972 protects individuals from sex or gender-based discrimination, including discrimination based on gender-identity, in educational programs and activities that receive federal financial assistance.

Northeastern’s Title IX Policy prohibits Prohibited Offenses, which are defined as sexual harassment, sexual assault, relationship or domestic violence, and stalking. The Title IX Policy applies to the entire community, including male, female, transgender students, faculty and staff.

If you or someone you know has been a survivor of a Prohibited Offense, confidential support and guidance can be found through University Health and Counseling Services and the Center for Spiritual Dialogue and Service clergy members. By law, those employees are not required to report allegations of sex or gender-based discrimination to the University.

Alleged violations can be reported non-confidentially to the Title IX Coordinator within The Office for Gender Equity and Compliance at titleix@northeastern.edu and/or through NUPD. Reporting Prohibited Offenses to NUPD does NOT commit the victim/affected party to future legal action.

Faculty members are considered “responsible employees” at Northeastern University, meaning they are required to report all allegations of sex or gender-based discrimination to the Title IX Coordinator.

In case of an emergency, please call 911.

Please visit https://www.northeastern.edu/titleix for a complete list of reporting options and resources both on- and off-campus.

International Tutoring Center​

The International Tutoring Center (ITC) provides current Northeastern University international and non-native English-speaking students with free, comprehensive English language and academic support. The ITC includes student-centered one-on-one tutoring sessions and workshops on reading, writing, and language and culture. For more on tutoring and workshops, see https://cps.northeastern.edu/academic-resources/global-student-success/international-tutoring.

WeCare​

WeCare is a program operated through the Office for Student Affairs. The mission is to assist students experiencing unexpected challenges to maintaining their academic progress. WeCare works with students to coordinate among university offices and to offer appropriate on and off campus referrals to support successfully resolving the issue. WeCare also provides information to faculty and staff to identify Northeastern resources and policies to help students succeed.

For more information see https://studentlife.northeastern.edu/we-care/. Call 617.373.4384 or email wecare@northeastern.edu.

Libraries​

Students can access research resources at the F.W. Olin library (Oakland) and through the Snell Library (Boston and online). The Snell Library collaborates with both the First-Year Writing and Advanced Writing in the Disciplines programs to support students’ information literacy. Online research tutorials can be found here: https://subjectguides.lib.neu.edu/researchtutorials/getstarted

Global Learner Support​

Northeastern University's Global Learner Support (GLS) offers "language, cultural, and academic support while promoting the development of intercultural competence and global understanding." They offer tutoring, workshops, and much more. Visit https://gls.northeastern.edu/ to learn more.