Week 12 – 11/30/2024

Agile Versus Waterfall: Picking the Right Tool for the Job

As a senior in college, I’m starting to think more seriously about what it will actually be like to work on projects in the real world. I recently read a blog post that compared and contrasted Agile and Waterfall project management methodologies, and it really helped me understand the importance of choosing the right approach for different types of projects. This aligns perfectly with what we’ve been discussing in my class about the need for both strategic planning and adaptability.

The blog post “Agile vs. Waterfall: Understanding the Differences” by Mike Sweeney explained that Waterfall is a very linear, sequential approach, where each phase of the project must be completed before moving on to the next. It’s kind of like building a house – you need to lay the foundation before you can put up the walls. This makes Waterfall a good choice for projects where the requirements are well-defined and unlikely to change, like in construction or manufacturing. In these industries, making changes mid-project can be super costly and impractical, so having a clear plan from the outset is essential.

Agile, on the other hand, is all about flexibility and iteration. The project is broken down into short cycles called sprints, and the team continuously reevaluates priorities and adjusts its approach based on feedback and new information. This makes Agile a great fit for projects where the requirements are likely to evolve over time, such as software development. In software development, client needs and market trends can change rapidly, so being able to adapt is crucial.

One of the biggest takeaways for me was the realization that choosing the right methodology is crucial for project success. I used to think that being flexible was always the best approach, but now I understand that structure and predictability can be equally important in certain situations. The key is to carefully assess the project requirements and choose the methodology that best aligns with those needs.

As I prepare to enter the professional workspace, I feel much more confident in my ability to approach projects strategically. Thanks to this blog post, I now have a better understanding of when to use Agile versus Waterfall. For instance, if I’m working on a software project that involves a lot of client interaction, I’d probably lean towards Agile. But if I’m managing a marketing campaign with well-defined objectives, Waterfall might be a more appropriate choice.

The real-world examples provided in the blog post were super helpful in illustrating how these methodologies are applied in different industries. This practical insight will definitely be valuable as I transition from the academic world to the professional world.

Blog link: https://clearcode.cc/blog/agile-vs-waterfall-method/

From the blog CS@Worcester – computingDiaries by hndaie and used with permission of the author. All other rights reserved by the author.

Sunday, September 15, 2024

This week I was introduced to Object-Oriented Design Principles. In this week’s blog, I will be discussing what object-oriented design principles are and how these principles help with creating software so that it is easy to maintain.

The Medium blog post by Ravi Patel “Understanding Object-Oriented Design Principles” offers an overview of major object-oriented design principles and how they help to the creation of successful and maintainable software. Object-Oriented Design (OOD) is a software design methodology that views the program as a collection of interacting objects, each representing an instance of a class. Ravi goes on to discuss the fundamental principles, encapsulation, abstraction, inheritance, and polymorphism.

Encapsulation is the process of grouping data and methods that operate on it into a single unit or class while restricting access to certain of the object’s components. This aids in concealing the internal state and requires all interactions to be conducted through an object’s methods.

Abstraction is the process of simplifying complicated systems by modeling classes based on key traits and behaviors, while obscuring unneeded information. This focuses on an object’s actions rather than its methods.

Inheritance allows a new class to inherit characteristics and methods from an existing class, enabling code reuse and establishing a hierarchical connection between classes.

Polymorphism allows objects to be viewed as instances of their parent class rather than their own. This enables the use of a single interface for a broad range of activities, increasing code flexibility and extensibility.

I chose this blog post because it helped me understand the principles better. After this week’s reading I now understand that object oriented principles is a theory that helps developers in how to think about and build code that is easier to work with, simpler to understand, and requires less maintenance overall. When working on my POGIL activity with my team this week, there was a question that asked us to define the principles without looking them up. We defined the principles as follows:

Abstraction is simplifying code
Encapsulation is adding code to already existing code
Polymorphism is many forms of code/methods
Inheritance are classes and their super classes and constructors

Our definitions were not entirely wrong. We could gather what each principle meant to an extent. I see myself applying these principles in my future projects. It would help create readable code that can also be modified easily as needed. This week’s material made me understand that not all long code is helpful. The simpler the code is the better it is for the next developer to read it. When I usually code, I add a lot of unnecessary code that does not need to be there. I hope to improve my code writing skills as I learn more.

Blog link: https://medium.com/@ravipatel.it/understanding-object-oriented-design-principles-0c1e48207c89  

From the blog CS@Worcester – computingDiaries by hndaie and used with permission of the author. All other rights reserved by the author.