CS 3100: Program Design and Implementation II

Lecture 22: Teams & Collaboration

©2026 Jonathan Bell & Ellen Spertus, CC-BY-SA

Highlights of Survey Results

How are you feeling about CS 3100?

• Discuss every row → One of the ways we try to help students is with office hours

Why not office hours?

• Call out rows 4 and 5

Asking for help is an important skill and being wrong is okay

• It's natural to feel reluctant to ask questions, but...

• You will need to ask questions to succeed at your co-ops.

• It's also vital if you are doing research.

• Ask yourself what you think of people who ask questions or make mistakes.

Share my experiences

• When I visited UCB team
• Tell story about grad student failing at research
• I write my strongest letters for people who ask questions and don't mind making mistakes

One of my (many) recent mistakes

• Note 5 hidden messages with more details! → Let's do an exercise

Exercise: Tell someone you don't understand something

• "I have no idea what Prof. Spertus is talking about half the time."

• "I spent a whole lecture wondering why Ellen was talking about some guy named Jason."

• Now it's your turn. Your confession doesn't have to be true.

Credit for exercise: Prof. Judy Goldsmith, University of Kentucky

• See if any students are willing to say a sentence to the group.
• Have everyone make a real or fake confession to other students. → Switching to something more serious, there were some survey responses that especially concerned me

Concerning responses

• Two Boston students said this class sometimes makes them want to die.

• If you feel that way, get help. See Find@Northeastern.

• Getting good grades or a job does not cure depression.

• An Oakland student wrote: "I feel like the teacher isn't understanding and blames any lack of knowledge on yourself instead of her teaching."

• Thank you for sharing your feelings.
• That is not how I feel about students.
• I am sorry for giving you that impression and hope you will give me another chance.

Learning Objectives

After this lecture, you will be able to:

1. Explain key advantages of working in a team and sharing information with your team
2. Describe the stages of team formation and strategies for establishing productive working agreements
3. Describe the HRT pillars of social interaction and strategies for resolving team conflicts
4. Seek and receive feedback effectively
5. Write clear and specific GitHub issues, pull requests, and comments
6. Ask technical questions effectively

Professional software development is almost always done on teams. → Who should be on a team?

The Question This Lecture Answers

Team projects rarely fail because of technical skill. They fail because of collaboration.

Today you'll learn:

• The principles that make collaboration work (HRT, scalable knowledge)
• The practices that professional teams use (CI, PRs, code review, issues)
• The agreements that prevent conflicts (team charters, shared expectations)

These separate teams that ship from teams that implode.

This is the central question of the lecture.

Frame everything that follows as answering: "How do we avoid the common failure modes?"

• Principles = HRT (Arc 2), scalable knowledge sharing
• Practices = GitHub workflow (CI, PRs, code review, issues)
• Agreements = team charters, explicit expectations

The promise: By the end of this lecture, you'll know what separates functional teams from dysfunctional ones—and you'll have practiced most of it already in labs.

Transition: In fact, you've already been building these skills...

Looking Ahead

• Midterm

  • Practice midterm distributed today
  • In-class review, next Monday
  • Exam, next Wednesday, March 18

• Assignment 5

• Group project

Introducing A5: Designing Services for Your Team (Individual Assignment)

A4's RecipeService bundled everything into one interface—scaling, conversion, import, search. That was intentionally problematic. A5 asks you to fix it by designing services aligned with actors:

Actor	A5 Service Responsibility	Group Project GUI Component
Librarian	Collections, import, search	Library View, Import Interface, Search
Cook	Step-by-step navigation	Recipe Details/Editor
Planner	Shopping lists, scaling, export	(Feature Buffet options)

Same architecture, CLI → GUI: Your A5 services become the foundation for the group project. Each teammate's GUI component consumes specific services—clean boundaries = parallel work without conflicts.

I will discuss on Wednesday how to approach the assignment. I recommend reading it before then.

• A4's RecipeService was a giant interface that did too much
• Problem: tight coupling, hard to test in isolation
• A5 asks: "Now that you see why that's bad, design something better"
• A good division will help with the team project...

Team Project: CookYourBooks GUI

You've met your team. Here's what you'll build together:

What you're building:

• Full JavaFX GUI for CookYourBooks
• Each team member owns one core feature:
  • Library View (browse cookbooks)
  • Recipe Details/Editor
  • Import Interface (OCR integration)
  • Search & Filter
• Plus shared infrastructure and "Feature Buffet" extras

The timeline:

• Now:
  • Team Charter (due Friday, March 13)
  • Final individual assignment (due Thursday, March 19)
• March 26: Design Sprint (wireframes, personas)
• April 9: Checkpoint 1 (core features)
• April 16: Checkpoint 2 (Feature Buffet)
• April 20: Final submission

The structure:

• One spec, released upfront
• Incremental delivery required
• Code review on all PRs

This lecture: The principles, practices, and agreements you need to succeed.

Set expectations:

• Not just divide and conquer
• Shared infrastructure, integration, and "feature buffet"
• Checkpoints require working features

→ Let's look at how software is created...

The Myth of the "10x Engineer"

The reality:

• Teams require multiple people with different skills → but bigger isn't always better

Brooks' Law

“Adding manpower to a late software project makes it later.”

— Fred Brooks

David.Monniaux CC BY-SA 3.0

Fred Brooks managed the development of IBM's System/360 computers and wrote The Mythical Man-Month (1975) to share what he learned about large software projects.

• Brooks later won the Turing Award. → What do you think is the reason behind the law?

Poll: Why do you think adding staff to a late software project makes it later?

• Acknowledge that the term "man-month" is dated.
• Poll should be open-ended.

Why Man-Months are Mythical

Brooks' Law: Communication Overhead Grows Quadratically

Amazon has the two-pizza rule: Teams should be small enough (5-8 people) to be fed by two large pizzas.

Brooks' Law (1975, The Mythical Man-Month):

• Adding people to a late project makes it later
• New members need onboarding
• More people = more coordination overhead
• n(n-1)/2 communication paths

Implication: Teams need to plan how they communicate upfront. You can't just throw more people at a problem.

Transition: There's another law about how teams affect software...

Conway's Law: Teams Shape Architecture

“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”

— Melvin Conway, 1967

Translation: Your software's architecture will mirror your team's structure—whether you plan for it or not.

Example: Three teams working on one app → three separate services that need integration

Inverse Conway: Design the team structure you want to match the architecture you need

Conway's Law in your project:

• 4 team members → 4 core ViewModels (Library, Recipe, Import, Search)
• Each ViewModel has a defined interface = clear responsibility boundary
• Shared infrastructure (navigation, theming) requires coordination across the team
• This is intentional—we designed the project structure to match the team structure

Conway's Law in industry:

• Microsoft's Windows team structure → Windows architecture (famously criticized)
• Amazon's "two-pizza teams" → microservices architecture

Inverse Conway Maneuver: Some companies deliberately restructure teams to get the architecture they want. We did this for you.

Transition: Brooks' Law tells us communication doesn't scale—so we need practices that do. But before we learn the practices, we need to understand the mindset that makes them work...

Debugging Teams (HRT)

“Engineering is easy. People are hard.”

— Bill Coughran, former SVP of Engineering at Google

The authors (Google engineers) present a strategy with three pillars:

• Humility
• Respect
• Trust

• Authors were Google engineers

Pillar 1: Humility

You are not the center of the universe (nor is your code!). You're neither omniscient nor infallible. You're open to self-improvement.

Without Humility:

• "I'm never wrong about code."
• "I don't need to ask—I'll figure it out myself."
• Refusing to acknowledge bugs you introduced
• Taking criticism of code as personal attacks

With Humility:

• "My mistake—let me fix it."
• "I don't know, but I'll learn."
• Accepting that your code can be improved
• Being willing to change your mind

Humility isn't self-deprecation—it's honest self-assessment and openness to growth.

Core insight: Humility is about accurate self-perception, not false modesty.

The paradox: The best engineers are often the most humble because they've seen enough to know how much they don't know.

→ The second pillar is about how you treat others...

Pillar 2: Respect

You genuinely care about others you work with. You treat them kindly and appreciate their abilities and accomplishments.

Without Respect:

• Ignoring teammates when they speak
• Taking credit for others' ideas
• Dismissing suggestions without consideration
• "Whatever..." or "That's a dumb idea."

With Respect:

• Listening to understand, not just to respond
• "Great idea, Sarah!" — giving credit
• Assuming competence and good intentions
• Valuing contributions different from yours

Respect isn't just politeness—it's treating teammates as capable and valuable colleagues.

Why it matters for teams:

• People who feel respected contribute more ideas
• Disrespect creates psychological unsafety—people stop speaking up
• Credit-hogging destroys collaboration faster than almost anything

Respect also means: Direct, honest feedback. "You're doing great!" when they're not isn't respect—it's condescension.

Transition: The third pillar enables everything else...

Pillar 3: Trust

You believe others are competent and will do the right thing. You're OK with letting them drive when appropriate.

Without Trust:

• Hovering over teammates, checking every keystroke
• Rewriting others' code without discussing it
• Requiring approval for every small decision
• "Let me just do it myself—it'll be faster."

With Trust:

• Delegating without micromanaging
• Giving space to make (and learn from) mistakes
• Discussing before rewriting someone's work
• Trusting teammates to ask for help when needed

Trust isn't blind faith—it's giving people the benefit of the doubt and room to grow.

Core insight: Trust is what allows teams to work in parallel. Without it, everything becomes sequential bottlenecks.

Why it matters for teams:

• Micromanagement destroys morale and slows everything down
• People can't grow if they're never allowed to make mistakes
• Rewriting code without discussion signals "I don't respect your work"

Trust is built, not given: Start with reasonable trust, then adjust based on evidence.

→ Let's see all three pillars working together...

HRT in Practice: All Three Together

Humility

• Admit when you don't know something
• Accept that your code can be improved
• Be willing to change your mind
• Recognize others' valuable perspectives

Respect

• Give credit where it's due
• Listen to understand, not just to respond
• Assume competence and good intentions
• Value contributions different from yours

Trust

• Delegate without micromanaging
• Give space to make and learn from mistakes
• Don't rewrite others' code without discussion
• Trust teammates to ask for help when needed

⚠️ Not everyone who talks the talk walks the walk.

If you find yourself in a toxic team, get out!

The test: Think about your best team experience. Which pillars were present? Think about your worst. Which were missing?

→ HRT is the mindset. Now let's see how professional teams put these principles into practice with specific tools and workflows...

How Professional Teams Ship Code

Modern software teams don't just write code—they have processes to keep the codebase healthy.

Concept	What It Is	Why It Matters
Issues	Tracking system for bugs and features	Keep track of progress
Commits	Snapshots of code	Enables collaboration
Continuous Integration (CI)	Automated tests that run on every commit	Catches bugs before they reach users
Pull Requests (PRs)	A proposal to merge your changes into the shared codebase	Creates a checkpoint for review
Code Review	Teammates read and comment on your code before it's merged	Catches issues, shares knowledge

You'll use all these in your group projects. Let's understand each one.

→ Issues

Anatomy of a Good GitHub Issue

Bad issue

Title: "Unable to login"

Body: "It doesn't work. Please fix."

Good issue

Title: "Login fails silently when password contains special characters"

Body:

1. Go to login page
2. Enter username "testuser"
3. Enter password "p@ss#word!"
4. Click "Sign In"
5. Nothing happens, no error displayed

Expected: Error message or successful login

Environment: Chrome 120, macOS 14.2

See Pawtograder issues.

→ Let's now look at commits

Commits: Saving and Sharing Your Work

Version control lets teammates work on the same codebase simultaneously—without overwriting each other's changes.

What is a commit?

• The unit of change in Git
• A snapshot of your work at a point in time
• Ideally represents one logical change
• Includes a message describing what and why—make it meaningful:
  • ❌ fix bug
  • ❌ WIP
  • ✅ Add regex validation for password special characters
  • ✅ Display error toast when login validation fails
  • ✅ Fix silent login failure #106

Include issue numbers for mutual links.

Keep the first line of the commit message brief (≤50 chars) for display on GitHub.

• Call out issue number in last commit message → Why keep commit messages to 50 characters?

How GitHub Displays Commit Messages

• The commit message is 50 characters to fit in the code browsing view.
• There can be additional longer lines. → Here's what you see if you click through to a commit...

How GitHub Displays Commits

→ Let's know look at how we know commits are safe...

Continuous Integration (CI)

You've been using CI all semester—the autograder that runs when you push code.

What CI does:

• Runs automatically when code is pushed
• Compiles the code
• Runs all tests
• Reports pass/fail status

In professional teams:

• CI runs on every Pull Request
• Code can't be merged if CI fails
• "The build" = CI passing
• "Breaking the build" = your change caused CI to fail

When the build is broken, nobody on the team can merge their work until it's fixed.

That's why it's best to work on a branch...

Connect to their experience:

• The autograder IS continuous integration
• Every time you push, it compiles and runs tests automatically
• In professional settings, the whole team shares one CI pipeline

Why "breaking the build" matters:

• If CI fails on the main branch, everyone is blocked
• This is why teams use branches and PRs—to catch failures before they affect everyone

Transition: But wait—what's a "branch"? Let's cover that before we talk about PRs...

Git Branching: Working in Parallel

• Individual work is done independently on branches.
• It's only merged into main after review.
• If change simultaneously happens on multiple branches, it can be hard to merge.
• That's one reason clean service boundaries matter.

→ To get a review, make a pull request...

Pull Requests: The Gateway to Shared Code

A Pull Request (PR) is a formal proposal: "I'd like to merge these changes into our shared codebase."

The workflow:

1. Create a branch for your feature
2. Write and commit your code
3. Push and open a Pull Request
4. CI runs automatically
5. Teammates review your code
6. Address feedback, update PR
7. Once approved + CI passes → merge

Why not just commit to main?

• Protects the shared codebase
• Creates a review checkpoint
• CI catches issues before merge
• Discussion happens in one place
• Easy to revert if needed

You can look at Pawtograder PRs

PRs create a structured place for discussion before code becomes permanent.

→ Code review occurs in steps 5-6

Code Review: Teammates Read Your Code

Before your PR is merged, teammates read your changes and leave comments.

What reviewers look for:

• Does the code work correctly?
• Is it readable and maintainable?
• Does it follow team conventions?
• Are there edge cases not handled?
• Are there tests?

Why teams do this:

• Catch bugs before they reach users
• Share knowledge across the team
• Maintain quality and consistency
• Mentor junior developers
• Document design decisions

→ Let's talk about code reviews and how they feel...

Poll: What do you want to hear from someone who reviews your code?

A. This code is perfect!
B. You should make all these changes...

• Don't actually give poll
• It's human nature to want to hear the first.
• More often, it will be the second.
• It's good to learn from feedback, but it's hard.

What Criticism Can Feel Like

→ Let's find a different way to frame it...

Revised poll

What do you want to hear from someone who reviews your code?

Would you like to be a better programmer today than you were yesterday?

Would you like your mistakes to be caught early?

• Don't actually give poll → Yes, you make mistakes. Do you know who makes mistakes...

Who makes mistakes?

My Experience: The five stages of dealing with a code review

1. Disbelief: "How could someone find so much to complain about in my code?!"
2. Anger: "How dare someone suggest that a hash-map of hash-maps isn't an efficient way of storing data?"
3. Bargaining: "Maybe if I add the comments the reviewer requested in one file, I won't have to fix the tricky Unicode issues in another."
4. Depression: "There was so much wrong with my code. How can I show my face to the person who reviewed my code?"
5. Acceptance: "Wow, my code is a lot better due to the feedback. This is a useful process, although I bet it's occasionally painful for everyone."

Remember: You Are Not Your Code

Source: Brian W. Fitzpatrick and Ben Collins-Sussman BY-NC-SA 3.0

• Picture is from Debugging Teams.
• Anyone recognize the code? It's from Unix. → Here's how you should interpret feedback...

The Underlying Message

→ Let's look at how to apply HRT to code review

Applying HRT to Code Review

❌ Without HRT

✅ With HRT

"This is wrong. Use a HashMap instead."

"Have you considered a HashMap? It gives us O(1) lookups instead of O(n)."

"Why would you do it this way?"

"I'm curious about this approach—what led you to this design?"

"This whole function needs to be rewritten."

"I'm having trouble following this function. Could we pair on simplifying it?"

(silence)

"Nice refactor on the error handling!"

Same technical goals. The HRT version treats the author as a capable colleague, not a subordinate to be corrected.

→ Let's look at what people learn from group projects

Team Dynamics

Let's see if we can do better...

• Teachers assign group projects because they want students to learn communication, collaboration, and teamwork.
• Unfortunately, what students often learn is that they don't like group projects.
• You can't avoid group projects, in school or in the workplace.
• We want you to learn how to work well in groups...

Tuckman's Stages of Team Formation

Conflict is normal and part of the process.

Tuckman's model (psychologist Bruce Tuckman):

1. Forming: Polite, guarded, everyone's on best behavior
2. Storming: Conflicts emerge—different styles clash. Uncomfortable but NECESSARY
3. Norming: Shared expectations form, trust develops
4. Performing: Team operates effectively, members compensate for each other

Key insight: Conflict (storming) is normal, not a sign of failure. The goal is to move through it productively.

Transition: How do teams move from storming to norming faster?

Team Charters Accelerate Norming

Explicitly discuss and document expectations before conflicts arise:

• When are we available to work together?
• How do we prefer to communicate?
• How do we handle deadlines?

• What does "done" mean for our work?
• How will we divide work and make decisions?
• What do we do when someone is blocked?

Example conflict prevented: A team member who starts work early and one who works best under deadline pressure can negotiate expectations upfront—rather than discovering the mismatch mid-project.

For this class: Your team charter is live now—it's your first team deliverable.

Team charters:

• Surface potential conflicts before they become problems
• Create a reference document to return to during disagreements
• Not a legal document—a shared understanding

This is why we polled you: We asked about working hours, communication styles, and availability to help form compatible teams.

Your first deliverable is live: The team charter is graded and sets the foundation for everything. Teams that skip this step or do it carelessly struggle later. Take it seriously—it's due March 13.

Transition: Team charters establish shared expectations. But even with good agreements, conflicts happen. Here's how to handle them...

Your First Team Deliverable: The Team Charter

This is not a formality—it's the foundation for everything that follows.

What you'll establish:

• Communication norms (when, where, how)
• Working hours and availability
• How you'll divide work
• How you'll make decisions
• What "done" means for your team
• How you'll handle missed deadlines

Why it matters:

• Surfaces conflicts before they happen
• Creates shared expectations to reference
• Accelerates your team through "storming"
• Gives you something to point to when things go wrong

This is graded. Take it seriously. Teams that rush through the charter often struggle later when conflicts arise and they have no shared expectations to fall back on.

The goal: Have the hard conversations now, while stakes are low and everyone is fresh.

→ Let's take a closer look at what you will do...

Completing Your Team Charter (due: Friday, March 13)

Step 1: Schedule a team meeting this week

• Everyone should be present for this conversation
• Don't just divide up sections and merge—discuss together

Step 2: Have the awkward conversations

• "What hours do you actually work?" (not what sounds good)
• "What happens if someone misses a deadline?"
• "How do we decide when we disagree?"

Step 3: Be specific, not aspirational

• ❌ "We'll communicate regularly"
• ✓ "We'll post daily updates in Discord by 9 PM"

HRT in action: Approach this with humility ("my preferences aren't the only valid ones"), respect ("everyone's constraints matter"), and trust ("we'll all follow what we agree to").

Emphasize: The charter is a living document. You can update it as you learn what works. But having an initial agreement is critical.

Common failure modes:

• One person writes it, others sign without reading
• Vague commitments that can't be enforced
• Assuming everyone has the same working style
• Not discussing what happens when things go wrong

The test: If a conflict arises in week 3, can you point to a specific line in your charter that addresses it?

Conflict Resolution: Six Steps

Step	Action	Example
1	Establish shared facts	"The build broke at 11 PM. Here's the commit."
2	Express feelings, not accusations	"I felt stressed when..." not "You always..."
3	Never presume intent	Assume good faith until proven otherwise
4	Remain calm	If triggered, step away and return later
5	Fight forward, not back	Focus on solutions, not blame
6	Escalate appropriately	Bring in a neutral third party if stuck

Key principle: "Fight forward, not back"

• Blame is backward-looking and unproductive
• Solutions are forward-looking
• "How do we prevent this next time?" > "Whose fault was this?"

Escalation isn't failure: Sometimes you need a neutral third party. That's mature, not weak.

Transition: Let's see these steps in action with a common team conflict...

Accountability: Be Someone Your Team Can Rely On

• Own your commitments: If you say you'll do something, do it—or communicate early if you can't. Don't wait until the deadline.
• Take responsibility for outcomes, not just effort: "I worked hard on it" isn't the same as "it's done and working."
• Support team outcomes: If a teammate is struggling, offer help before being asked. The team succeeds or fails together.

Accountability builds trust. When teammates can count on you, the whole team moves faster.

🤔 How did my admitting mistakes and apologizing change your opinion of me?

• Struggling silently isn't heroic—ask for help
• When you make a mistake, acknowledge it and focus on the fix
• If you finish early, ask what else needs doing
• Question is rhetorical

→ Part of accountability is being open to feedback...

Receiving Feedback Without Defensiveness

Your instinct may be to explain, defend, or minimize. Resist.

1. Say "thank you" before responding — it creates space between reaction and response
2. Ask clarifying questions — "Can you give me an example?"
3. Reflect before reacting — you don't have to agree immediately, but don't dismiss
4. Follow up — tell them what you changed. It encourages future feedback.

The discomfort is the point. If all feedback feels good, you're only hearing from people who tell you what you want to hear.

The feedback paradox:

• The most useful feedback is the most uncomfortable
• It reveals blind spots you didn't know you had
• Seek out people who will challenge you → Let's look at today's key takeaways...

Key Takeaways: What Separates Teams That Ship

Team projects rarely fail because of technical skill—they fail because of collaboration. Here's what makes the difference:

Principles

• HRT: Humility, Respect, Trust
• The discomfort of feedback is the point
• We hold you accountable to these

Practices

• CI catches bugs before they spread
• PRs create review checkpoints
• Issues and code review share knowledge
• Scalable communication beats O(n²)

Agreements

• Team charters accelerate norming
• Your first deliverable isn't code—it's alignment
• Fight forward, not back

Your first deliverable: The team charter is due March 13. Apply these principles this week with your new team.

Callback to the opening: We started with the question of what separates teams that ship from teams that implode. The answer: principles (HRT), practices (GitHub workflows), and agreements (team charters).

Looking ahead:

• Now: Team charter due March 13 — apply everything from today immediately
• Mar 26: Design Sprint (wireframes, personas, architecture)
• Checkpoint 1 (Apr 9) — core features must be working

Final thought: Technical ability gets you hired. Collaboration skills determine your trajectory. The best engineers aren't the ones who write the most code—they're the ones who make their whole team more effective.

Bonus Slide