CST 438 - Week 6

 Hey everyone,

This week in class, we explored two very different ways of approaching software development: the Agile method and the more traditional Plan-and-Document (Waterfall) method. I’ve heard these terms before, but actually comparing them side-by-side—and thinking about how they play out in real projects—helped everything click.

Starting Point: How the Two Mindsets Differ

One of the biggest differences I noticed is the mindset behind each approach.
Waterfall assumes that we can plan almost everything in advance. It feels like writing a detailed roadmap before even starting the engine. Agile, on the other hand, seems to accept that surprises will happen. Instead of a fixed map, Agile works more like a GPS rerouting along the way.

Planning: One Big Plan vs. Many Small Plans

In Waterfall, planning happens early and intensely. Before any coding starts, you produce big documents—requirements, design diagrams, timelines. It’s clean and structured, but also kind of intimidating. If something changes later (and things always change), it can feel like the whole plan collapses.

Agile flips this around. Planning still matters, but it happens in smaller chunks. Each sprint starts with a short planning session and ends with a review. This felt much more manageable to me—as if the project is broken into digestible pieces instead of one massive commitment.

Communication: Formal vs. Continuous

Waterfall seems to rely on formal checkpoints. You gather requirements once, review designs at specific stages, and communicate through documents.

Agile surprised me by how much communication it expects. Daily stand-ups, sprint retrospectives, demos… it feels more like an ongoing conversation. In our mock sprint, I noticed how helpful it was to talk frequently—we caught issues early because we weren’t waiting for the “next official meeting.”

Handling Change: Resistant vs. Welcoming

This was probably the biggest difference I took away.

In Waterfall, change can be disruptive because so much effort goes into early planning. Changing requirements halfway through means going back to update all the documentation, schedule, and design.

Agile treats change almost like a normal part of life. If a requirement shifts, the team adjusts the backlog or re-prioritizes the next sprint. It feels more flexible and realistic, especially for projects with unclear or evolving goals.

Deliverables: One Final Release vs. Frequent Iterations

Waterfall aims for a big, polished release at the end. Only after the whole process do users get to actually see the product. This can be risky if the final result doesn’t match what they expected.

Agile delivers small increments early and often. Users can try out pieces of the product as it evolves. I liked this idea—it reduces the fear of “Did we build the right thing?” because you’re constantly checking with users.

My Takeaway

After comparing the two, I realized that neither method is “better” in all cases—they're just suited for different situations. Waterfall works when requirements are stable and well understood, like building a bridge. Agile makes more sense when uncertainty is high and feedback is essential.

Personally, I found Agile more engaging because of its collaborative nature and flexibility. But I can also appreciate the clarity and structured approach of Waterfall.

Overall, learning the differences helped me understand why so many teams today prefer Agile—and when it might still be appropriate to rely on a more traditional, plan-driven method.

Comments

Post a Comment

Popular posts from this blog

CST 370 - Week 1

 Hey everyone, This week, we learned several important topics that form the foundation of computer science and programming. We started with GitHub and practiced using manual commands like git init, git add, git commit, and git push to manage our code. This helped us understand version control and how to keep track of changes when working on projects, especially when collaborating with others. We were also introduced to algorithms and learned what they are—step-by-step methods for solving problems. One example we focused on was Euclid’s Algorithm for finding the greatest common divisor (GCD) of two numbers. It uses a simple but powerful idea: repeatedly replace the numbers with GCD(b, a % b) until the second number becomes zero. We also practiced writing pseudocode, which helped us plan out algorithms in plain language before coding. We also had a homework assignment to help us further understand GitHub commands. Later in the week, we learned about graphs, both weighted and unweight...
Read more

CST 370 - Week 5

 Hey everyone! This week, I explored several important algorithm design techniques and deepened my understanding of how they are applied in solving complex problems efficiently. One of the key highlights was learning about Quick Sort , a widely used sorting algorithm that relies on the Divide-and-Conquer strategy. I now understand how Quick Sort works by dividing the array into smaller parts around a pivot, sorting those parts recursively, and then combining the results. I also learned about its efficiency and how its performance depends on the choice of the pivot. I also studied Binary Tree traversal methods, such as inorder, preorder, and postorder, and how each serves a specific purpose when working with hierarchical data. Alongside traversal, I learned how to calculate the height of a binary tree , which is a foundational concept for evaluating the balance and efficiency of tree-based data structures. I even added my insights on the class Discord group, explaining an easy calc...
Read more

CST 370 - Week 4

 Hey everyone! This week in class, I focused on two main things: learning about Merge Sort and reviewing for the upcoming midterm . We covered Merge Sort in detail, and it really helped me understand how divide-and-conquer algorithms work. I learned that Merge Sort breaks down an array into smaller parts, sorts each part, and then merges them back together in a sorted order. What stood out to me is how efficient it is, especially for large datasets, with a time complexity of O(n log n) . I found the recursive nature of the algorithm interesting, and practicing it helped me see how smaller problems can be solved independently and then combined to solve the larger problem. Aside from learning new material, a big part of this week was focused on reviewing for the midterm . I went over topics from previous weeks like brute-force algorithms, string matching, and graph traversal methods (DFS and BFS). I also spent time practicing problems and using flashcards to reinforce key concepts....
Read more