Embracing Chaos: Lessons From Four Semesters of Capstone Projects

When I designed this capstone for the first time in Fall 2024, the guiding principle was simple: give students as much chance to experience challenges of software engineering in the real world as possible. This means bringing in projects that either come from real clients’ demands or are much larger in scope compared to the typical course projects. Of course, this comes with risks. At the beginning, in an attempt to provide scaffolding for students, I have tried to manage and control the inherent uncertainties in these projects. Four semesters later and at the beginning of the fifth one, I have humbly learned that as the course matures, the level of uncontrollable chaos grows with it. And paradoxically, it is inside this chaos that the students grow. Their final projects stand as evidence of their emerging professional maturity.

In this essay, I want to explore how this instability shapes individual student experiences, as revealed through their final reflections across the semesters. Through this exploration, I examine the role I want to assume and the extend to which I want to calibrate this chaos so it is enough to push students forward, but not enough to push them over the edge?

Fall 2024: Foundational Chaos

We start our first Capstone semester with small ambitions. Modeled after Cornell’s Software Engineering course, I was confident that I had the lecture parts down. Through the Career Development Center and alumni, we were able to receive one project from a business, two from non-profit organizations, and two from faculty. All projects differ from one another in scope, scale, and clients’ technical ability. Students suddenly found themselves responsible not only for writing code but also for imagining what the client meant when they described what they wanted. Across the reflections, several similar themes emerged.

Learning to Translate Ambiguity Into Requirements: Students discovered very quickly that community organizations (or clients without technical background) do not speak in technical terms and that what clients want does not directly translate into technical requirements. Only through long, repeated conversations with the clients that requirements can be extracted from non-technical conversations. Even then, clarity and understanding only come through extensive rephrasing. They also learned to negotiate gently when clients requested impossible or unclear features and to keep stakeholders updated without overwhelming them. In other words, they learned that engineering work often begins long before the code process starts.

Technical Learning by Immersion: For groups working with highly technical clients, students emphasized how much new technology they had to learn quickly. Examples include ReactJS and TypeScript, frontend–backend integration via OpenAPI or custom APIs, UI/UX design standards and consistency, basic cloud/web hosting concepts, and Git workflows (branching, merging, collaborative version control). In addition, a common concluding theme of all these technical learnings was the meta skill: The most important thing I learned was how to learn new technical skills. Students realized that unfamiliar tools were not obstacles but inevitabilities.

Real Team Collaboration: I have intentionally arranged teams to have 4 to 6 students, and the clients were encouraged to scale their projects accordingly. In this setting, students faced genuine interdependence. Their contributions weren’t isolated homework assignments but interconnected components of a real system. There were still cases of slacking off, which were pointed out in students’ reflection. At the same time, the reflections recognized the importance of distributing responsibilities based on skill, interest, or necessity and maintaining internal accountability. Many noted that teamwork required more communication than expected, including communication they assumed would just happen.

The First Glimpse of Chaos: In this first semester, there were definitely uncertainties such as non-technical clients with organizational and financial constraints (regarding technical solutions), delivery pressures, and scope adjustments, integration challenges, and conflicting team schedules. What stands out is that, despite everything, students rarely complained about the chaos. I suspected that they had come to embraced it as part of the learning experience. This was demonstrated in their reflections, as many students wrote that they came into the semester unsure if they could build something for a real organization. By the end, the successful delivery of even a modest product had changed their self-perception.

Spring 2025: Structured Chaos

If Fall 2024 was the semester of foundational chaos, then Spring 2025 was the semester where chaos became structured, ambitious, and multidimensional. With three business clients and four student-defined projects, this cohort faced more variety, more pressure, and far more technical depth than the first. The students’ reflections reveal a set of powerful interconnected learnings.

Ambition Scales Faster Than Stability: The four self-defined projects reflected unrestrained ambition. Students designed ideas involving machine learning pipelines, augmented reality environments, and full-stack tools that rivaled small startup MVPs. However, these ambitions came with consequences. Three out of the four student-defined projects ultimately could not to reach their initial goals. There were significant revision of expectations, component redesigns, and complete redirection. Through this experience, students also learned how to quickly pivot while keeping the momentum.

Dramatically Expanded Technical Depth: Compared to Fall 2024, Spring 2025’s technical challenges escalated rapidly. Students wrote about having to learn about machine learning, augmented reality development tools and integration challenges, enterprise cloud systems (AWS IAM, policies, dashboards, monitoring), and many other things. This forced students to confront advanced concepts normally spread across upper-level electives. Many admitted being intimidated at first, but they repeatedly described the same turning point: Once I realized it was just math, statistics, and code, it became manageable. On the other hand, from my perspective as an instructor, it signals that technical aspects of projects are scaling with the modern demand of external clients. This is a price that I am willing to pay to maintain an experiential learning environment.

Professional Communication as a Discipline: The clients in Spring 2025 were more structured and more demanding. Students had to provide consistent and timely progress reports. They learned to take the initiative to seek meetings rather than wait for client, especially when there were looming issues with the progress. They also learned to handle unresponsiveness professionally without losing momentum and to negotiate shifting requirements. They also began to push for clarity when specifications were incomplete. Several students noted that the discomfort of nudging a client, especially a senior professional, was a major learning experience. They began to understand that communication in engineering is not optional but a core competency.

Fall 2025: Chaos as a Core Attribute

In this semester, I came to accept the fact that chaos is the defining structure of the course. The class took on four business clients and two self-defined projects. This semester’s student reflections were deeper, more introspective, and more candid than any prior cohort.

Learning Through Client Failure: Two teams experienced complete client collapse due to uncontrollable external issues. This forced them into a radical learning moment where they had to rebuild entire new projects from scratch in seven weeks. In this process, they learned to scope a new project under severe time pressure, to divide responsibilities aggressively, to set realistic but ambitious goals, and most importantly, to keep morale intact despite disappointment. The initial chaos had turn into a genuine professional adversity moment, and the students met it. In their reflections, I observed phrases that describe these crises as: humbling, motivating, transformational, and the moment everything clicked.

Rising Technical Bar and Engineering Judgement: Compared to previous semesters, the technical complexity of client demands jumped again. We now have projects that explore cross-architecture development, require integration with edge devices and drones, push for performance optimization under constrained environments, or need database migrations, API redesigns, and UI/UX refinements. As the students were no longer just learning technologies but also systems thinking, they discovered that sometimes, trade-offs are unavoidable, architecture is negotiable, and performance matters even when constraints exist.

Leadership and Delegation Under High Pressure: With the high technical pressure of this semester, many reflections mentioned the turning point when they realized the team would fail without clear delegation. The students learned that leadership meant to step up and accept the responsibility to lead and that delegation is not optional when the clock is ticking. We have a lot of strong personalities, and yet they learned to become effective collaborators at the end.

Spring 2026: Chaos as Professional Practice

By Spring 2026, the chaos itself was no longer particularly surprising. Seven teams were working on projects ranging from AI and machine learning systems to business workflow applications, edge computing, biomedical devices, and full-stack software platforms. The technical problems remained difficult, and the clients remained unpredictable in all the usual ways. But the student reflections increasingly focused less on the novelty of these challenges and more on what they had learned about being responsible for an entire software project.

The Things Outside of Coding Are Part of the Job: One of the strongest themes in the reflections was the realization that successful software development is not defined solely by technical ability. Communication, documentation, scheduling, presentation, requirements clarification, and stakeholder management were no longer described merely as inconveniences but recognized as part of the engineering process itself. One student summarized this transition particularly well by observing that the course exposed them to the things outside of just coding that are needed to be in the professional world. This was perhaps the clearest evidence yet that students were beginning to see themselves less as programmers completing assignments and more as software engineers responsible for outcomes.

Communication Became Infrastructure: In earlier semesters, students learned that they needed to communicate with clients. By Spring 2026, their reflections went further. Communication had become something that had to be deliberately maintained. Client conversations needed to be documented. Decisions needed to be recorded. Questions had to be asked before assumptions hardened into implementation. When clients were unavailable, teams had to decide how long they could continue independently and when they needed to escalate. When clients described an outcome rather than a technical specification, students had to translate that outcome into something feasible. Communication, in other words, became part of the project’s infrastructure.

Teamwork Became Accountability: The reflections were also considerably less romantic about teamwork. Large teams created opportunities for specialization and ambitious projects, but they also created dependencies. Uneven participation, missed communication, incompatible schedules, and delayed work could affect everyone else. Several students recognized that behavior that might merely cost points in an ordinary group assignment would have consequences in a professional environment. Some found this frustrating. One student explicitly described the stress of compensating for teammates whose lack of communication or action would likely have professional consequences in an actual workplace. Yet this frustration itself became part of the experience. Accountability was no longer an abstract professional competency discussed in lecture as students were experiencing what happens when accountability is absent.

The Limits of Productive Chaos: Spring 2026 also made clearer to me that there is a boundary between productive uncertainty and simply leaving students unsupported. Some students wanted more technical guidance, more direct group meetings, or earlier intervention when teams had made little progress. Others valued precisely the independence that forced them to figure things out themselves. One student captured the tension almost perfectly: they understood that I should not solve the team’s problems for them, but wanted more explanation of why particular decisions were problematic when I intervened. This is probably the most important lesson I took from the semester. The goal cannot be to eliminate chaos. But neither can I simply create uncertainty and call it experiential learning. My responsibility is increasingly to decide when not to intervene, when to ask questions, when to explain the consequences of a decision, and when the students genuinely need help before productive struggle becomes pointless struggle.

Four Semesters of Chaos, and Learning When to Intervene

The first thing that went out the window, almost immediately, was my lecture plan. The contents remained largely the same, but their order increasingly had to follow the projects rather than the syllabus. Client meetings and requirements engineering moved forward because teams needed them immediately. Some technical materials moved backward because projects had not yet reached the point where those ideas mattered. Other topics suddenly became urgent because one team’s problem revealed something the entire class needed to discuss. By Spring 2026, the weekly debriefs had sometimes become more important than the lecture I had prepared.

This has gradually changed how I understand my role in the course. I started in Fall 2024 believing that my job was to design enough structure to safely expose students to realistic projects. Four semesters later, I think my job is closer to maintaining the boundaries within which useful chaos can happen. I cannot control whether a client responds on time, whether an API behaves as promised, whether six students coordinate perfectly, or whether a design decision made in week four becomes painful in week eleven. Nor should I necessarily want to.

What I can control is whether students have enough support to recover. I can give them ways to reason about requirements before the requirements become code. I can force uncomfortable conversations about team contribution before resentment becomes irreversible. I can ask why they made a decision rather than simply tell them it was wrong. And when something genuinely exceeds what students could reasonably be expected to recover from, I can step in. That distinction between protecting students from failure and ensuring that failure remains recoverable may be the most important thing these four semesters have taught me.

Four semesters have convinced me that when students are given real responsibility, real consequences, and enough support to recover from mistakes, uncertainty becomes more than an obstacle to learning. It becomes part of what they are learning to manage. I still do not know exactly where the line is between productive struggle and pointless struggle. In Fall 2026, I have started to discover an entire new host of uncertainties relating to team dynamics and client requirements. But I know now that my job is not to eliminate that uncertainty. It is to keep it recoverable.