Teaching

Capstone course

CIS 4398 Projects in Computer Science

Temple capstone course focused on authentic software project work, planning, stakeholder communication, teamwork, and delivery.

Visit capstone course

Design course

CIS 3296 Software Design

Course site for software design, system structure, design thinking, and collaborative software practice.

Visit software design course

In my experience as a learner, I have always found that I learn better by working with others. Early computing education often isolates students to reduce cheating concerns, but professional software work depends on collaboration. Senior-level courses begin to move in that direction, and I think that shift matters. It is a more realistic educational goal, and it sits at the center of how I teach.

My teaching philosophy is grounded in the idea that software engineering is a human and collaborative practice. Students need room to learn from each other, explain their thinking, negotiate tradeoffs, and adapt as projects change. I want classrooms to feel less like a sequence of isolated technical exercises and more like sociotechnical environments where planning, communication, coordination, and implementation are all part of the learning.

That is a big reason I care so much about project-based courses, especially Projects in Computer Science. I want students to practice the transition from coursework to authentic software work while they still have the support of an active classroom. The examples below reflect that approach through three recurring activities: Hackathon Ice Breaker, Event Storming, and Story Point Poker.

When I was in undergrad, I always felt that I learned better when I worked with a group, learning from others but also teaching others in the process. In my Projects in Computer Science capstone course, discovering team members' skills early is incredibly important to student success and learning. This is why I had students participate in a hackathon-style activity on the first day of class. Before the 2020 pandemic, hackathons were regularly hosted in Philadelphia by multiple universities, including Temple University. These events gave students a chance to solve open-ended problems together, often under time pressure and with unfamiliar tools.

To bring some of that energy into the classroom, I had students form random teams and build a piece of software that would help them keep up with course assignments by using my syllabus API, where I store class due dates and events. The point was not just to write code quickly. It was to help students start communicating early, discover each other's strengths, and begin functioning as a team in a low-stakes but authentic project setting.

A workshop I incorporate early in the ideation phase of a projects course is Event Storming. Like brainstorming, Event Storming asks students to identify the user-driven events in their software, not just the technical components. That challenges them to think about user goals, system behavior, and project scope in a way that coding alone often does not. It involves identifying the domain and problem, creating a big-picture view of the system, breaking it down into smaller components, mapping the flow of events, identifying missing events, and refining the model.

The goal is to create a shared understanding of the domain and its requirements while also surfacing ambiguities, assumptions, and coordination challenges. Event Storming is deeply collaborative, and I sometimes invite industry guests to participate as facilitators or stand-in stakeholders. That gives students exposure to real-world perspectives and helps them practice the kind of communication that software teams need when they are trying to align around a problem before implementation begins.

Another active learning exercise that I use in my classroom is Story Point Poker, which helps teams estimate the effort required to complete a task. Students assign values to tasks based on complexity, difficulty, and uncertainty, then use those estimates to reason about pacing and scope. The exercise is highly collaborative, involving group discussion and negotiation to arrive at a shared understanding of the work.

I like this activity because it makes coordination visible. Students have to explain assumptions, listen to each other, negotiate disagreement, and think critically about what it takes to complete a feature in a real team environment. It helps them develop important project management habits such as estimation, prioritization, delegation, and revision. It also reinforces that good software work depends on conversation, not just individual implementation.

Across all three activities, the larger goal is the same: I want students to experience software engineering as a collaborative, communicative, and human-centered practice. These exercises help students learn from each other, encounter authentic project constraints, and build habits that transfer into real software teams. They are also a big part of why my teaching and research stay so closely connected.

• I use project-based learning to make software process visible.
• I design activities that help students talk through requirements, system structure, and tradeoffs together.
• I try to give students tools and workflows that feel current and practical, including GitHub, Miro, Jira, Mermaid, and AI-assisted development tools.
• I want students to engage AI tools critically, as part of a broader software process rather than as a shortcut around thinking.
• I care a lot about documentation and presentation because good software work depends on both.
• I want capstone students to experience the realities of coordination, revision, and team communication, not just implementation.

Students working with me should expect iteration, candid feedback, and a strong push toward clarity. I want teams to leave a course not only with a working project, but with a better sense of how software work actually happens in practice, including how communication, coordination, and AI-mediated workflows shape that process.