Be Intentional
17 Dec 2025
Web Development = Software Engineering?
At the beginning of ICS 314, I thought software engineering was mostly about learning how to build web applications. Since we worked with technologies like React, Next.js, PostgreSQL, and GitHub, it was easy to assume the main objective was mastering modern web development. While web development skills were definitely a major takeaway, I eventually realized that they were not the core purpose of the course. Instead, this class taught me how to think about software engineering as a structured yet flexible discipline—one that involves planning, communication, design decisions, and adapting to uncertainty just as much as writing code.
Learning to Work with Uncertainty
One of the most impactful concepts I learned was Agile Project Management. Agile project management is an approach to organizing work that emphasizes flexibility, short-term planning, and continuous feedback. Rather than defining every detail at the start of a project, Agile assumes that requirements will change and that uncertainty is unavoidable. The goal is to make steady progress through small iterations, frequent check-ins, and constant reevaluation of priorities. This way of thinking changed how I approach teamwork, because it values responsiveness over rigid planning. In this class, we practiced a specific Agile-style method called Issue-Driven Project Management (IDPM). IDPM is a lightweight project management process where all significant work is broken into small, clearly defined tasks, each represented as a GitHub issue. These issues are tracked on project boards, assigned to individuals, and grouped into milestones with fixed deadlines. The intention behind IDPM is simple but powerful: everyone always knows what they should be working on, progress is visible, and problems surface early instead of being hidden until the end.
My experience with IDPM in the final project milestones showed me how closely project management is tied to human behavior. During Milestone 1, my team was overly optimistic. We underestimated the time required for setting up the development environment and designing the database schema and mockup pages, which made deadlines feel tighter than expected. This taught me that unrealistic optimism and unjustified confidence are real risks in software engineering. By Milestone 2, things improved significantly. Our issues were better defined, communication was consistent, and work progressed smoothly. Milestone 3, however, revealed another reality: even with a solid system in place, communication can break down. Meetings became less frequent, some members procrastinated, and a few of us had to take on more responsibility to finish the project. That experience reinforced the idea that project management tools support a team, but they cannot replace accountability and communication.
Design Patterns as Structure, Not Rules
Alongside project management, design patterns became one of the most important concepts I took away from ICS 314. Design patterns are general, reusable solutions to recurring software design problems. Rather than providing exact code, they describe relationships between components and outline structures that have proven effective over time. What stood out to me was that design patterns are not about making code more complicated—they are about making systems more understandable, adaptable, and maintainable. This course pushed me to think about design patterns more broadly as a way of thinking. Design patterns encouraged me to plan structure before implementation and to consider how different parts of a system interact. Instead of coding on the fly, I started focusing on separating concerns, building modular components, and thinking about how the project could scale over time. Whether it’s desktop software, mobile applications, or large backend systems, the same design principles help prevent systems from becoming fragile and difficult to maintain.
Design patterns also played a major role in teamwork. By organizing our project into modules and clearly defined layers, multiple people could work concurrently without constantly interfering with each other’s changes. This reinforced the idea that software engineering is rarely an individual activity. Design patterns provide a shared structure and vocabulary, making collaboration more efficient and helping teams communicate design decisions clearly as projects grow in complexity. I also learned that patterns are guidelines, not rules. For example, the Singleton pattern can easily become an anti-pattern if misused. Understanding these trade-offs showed me that good software engineering requires judgment, not just blindly applying best practices—knowing when not to use a pattern is just as important as knowing how to implement one. Reflecting on this, I realized how these ideas extend beyond just the code I write.
Beyond Web Applications
I can definitely see myself using both Agile principles—especially IDPM—and design patterns in other areas, including professional and non-technical contexts. Looking back on our ICS 314 project, I noticed how breaking work into small, manageable tasks and keeping progress visible made it easier to adapt when things didn’t go as planned, just as it did in our project. Similarly, design patterns helped me step back and see the bigger picture of how different pieces fit together, which is useful whether I’m organizing a team, coordinating a research project, or working on a backend system. Ultimately, combining flexible project management with intentional design made the work feel more manageable and collaborative—it’s a mindset I can carry into almost any project, not just coding.
Managing Risks
Finally, this course highlighted how unavoidable risk is in software engineering. Project risks—such as unclear requirements, poor project planning, technical complexity, poor communication, and scope creep—are not exceptions; they are expected challenges. Our project experienced many of these firsthand. Some mitigation strategies worked early on, such as frequent meetings and clearly scoped issues, while others failed later when assumptions replaced communication. This showed me that managing uncertainty is an ongoing process, not something that can be solved once at the beginning of a project.
Working with Intention
Overall, this class reshaped how I understand software engineering. It is not just about building something that works, but about building something intentionally. Agile project management taught me how to remain flexible without losing direction. Issue-Driven Project Management showed me how structure can support progress without becoming restrictive. Design patterns helped me think critically about system design instead of relying on trial and error. Even when parts of our project fell apart, those moments became the most valuable learning experiences. Software engineering is ultimately about adapting to change, making informed decisions, and working effectively with others.