Category Archives: CS@Worcester

Understanding the Twelve Principles of Agile Software

The 12 Principles of Agile Software explained

For this professional development entry, I chose to read the article titled The Twelve Principles of Agile Software Explained from the Agile Alliance website. The article provides an overview of the core ideas that shape the Agile Manifesto and explains how they guide the way modern software is built. What immediately caught my attention was how the principles focus on people, teamwork, and adaptability rather than strict processes or heavy documentation. The article highlights that Agile is not simply a development framework but a philosophy centered on collaboration and continuous improvement. It emphasizes that successful teams listen to their customers, respond to change quickly, and work together to deliver valuable software frequently rather than saving everything for one big release.

I found this resource helpful because it connects directly with what we have been studying in CS-343 about software processes and team communication. In many group projects, I have experienced situations where rigid planning or lack of communication slowed progress. Reading this article helped me see that Agile’s emphasis on flexibility and open dialogue could have prevented some of those problems. The principle that stood out to me most was “responding to change over following a plan.” This idea made me realize that while planning is important, being adaptable is even more valuable. Real-world projects rarely go exactly as expected, and being able to adjust quickly is a skill that separates good teams from great ones.

Another key takeaway for me was the focus on sustainable development. The article explained that teams should maintain a consistent pace and avoid burnout, which is something I think every computer science student can relate to. It is easy to fall into a cycle of late nights and last-minute fixes, but this principle reminded me that long-term quality depends on balance and discipline. The principle about motivated individuals also resonated with me. It stated that the best results come from trusting team members and giving them the environment and support they need to succeed. I have noticed this in my own coursework; when everyone feels respected and valued, collaboration becomes smoother and creativity increases.

The article also touched on the importance of reflection, encouraging teams to pause regularly to discuss what went well and what could be improved. This aligns perfectly with the concept of continuous improvement that we discuss in class. I learned that retrospectives are not just about fixing mistakes but about strengthening the team’s process as a whole. Moving forward, I plan to apply these ideas in future projects by promoting open communication, being willing to adjust plans when needed, and supporting my teammates in maintaining a healthy work rhythm.

Overall, this resource gave me a deeper understanding of what it truly means to work in an Agile environment. It showed me that Agile is not about speed but about building smarter, more collaborative, and more human-centered teams. The twelve principles serve as a strong foundation for both professional development and teamwork, and I believe they will continue to guide me as I grow in my career as a software developer.

From the blog CS@Worcester – Life of Chris by Christian Oboh and used with permission of the author. All other rights reserved by the author.

BPM On the Up & Up

With the technological advances and innovations in business continue to exponentially grow within their practices. The biggest challenge is all the pressure they face to stay afloat. From high climbing costs to having the fiercest competition with other companies. Long term, this causes danger to viability and businesses cannot afford to screw up continuously. To address these issues, a software has been implemented that eventually became the foundation of “digital transformation”, according to Digital Journal.

This is called Business Process Management (BPM), a software providing tools to quote “streamline processes, manage compliance, and adapt to shifting market conditions”. BPM is used to touch various different areas like different departments, locations, and IT systems. A revolutionary tactic has been made here, due to this process helping managers efficiently track and pinpoint errors & inefficiencies. Also for the team members, they can have a clear understanding of their goals and mission(s). 

Speaking of efficiency, this is essentially the first and most important benefit (arguably) that users hopefully will recognize. A lot more tasks can be completed in a higher-level manner. Let’s use a couple of examples: finance and healthcare. To treat and prevent illnesses, increased automation creates higher capacity. For financing, provider automation keeps secureness over companies against fraud and error. This translates to transparency, where these companies get to view their status and performance, in turn increasing accountability.

Despite the pros, all ideas come with its cons. BPM is not a straightforward process that is easily implemented whatsoever. Some businesses and organizations are limited in terms of skill gaps, fear of change and redesign complexities. In order to resolve this, companies need to broaden their vision by being open to the idea of BPM. Seeing the benefit will lead to greater outcomes in the performance as a whole.

Why is this important to discuss? The business industry is constantly changing, from the amount of businesses being formed, their structure outlines, idea creations, improving outcomes, etc. Depending on the size of the business (whether it’s yours or you work for one), there needs to be some sort of structure and process to have smooth outputs and less friction. For me personally, I knew that all businesses had their own processes in terms of how they’re run, but BPM is a new term I had never really learned or tapped into.

Moving forward, with the knowledge of programming and software development that I’m currently learning through a curriculum, I can hopefully bring a new/different perspective into a business when I am ready to delve deeper into the work field. Maintaining business process management will improve productivity, so it is not something to ignore at all. 

Source: BPM software and the move toward smarter business practices – Digital Journal

From the blog CS@Worcester – theJCBlog by Jancarlos Ferreira and used with permission of the author. All other rights reserved by the author.

Development Environment

Development Environments in Software Process ManagementDownload

From the blog CS@Worcester – dipeshbhattaprofile by Dipesh Bhatta and used with permission of the author. All other rights reserved by the author.

Blog Entry: Duck Simulator

Summary of the Resource

The resource I explored is the Duck Simulator project from the article “Design Patterns: The Strategy Pattern in Duck Simulations” by Head First Design Patterns (https://www.oreilly.com/library/view/head-first-design/0596007124/ch06.html). The simulator features different types of ducks like Mallard, Redhead, and Rubber ducks with behaviours such as flying and quacking. What’s particularly interesting is that these behaviours aren’t hard-coded into the duck classes; instead, they can be assigned or changed dynamically at runtime. This design highlights important object-oriented programming concepts, including polymorphism, encapsulation, and code reusability. It also demonstrates how the strategy design pattern allows developers to build flexible, scalable, and maintainable programs. The simulation is not only educational but also fun, giving a visual and interactive way to understand abstract programming concepts.

Why I Chose This Resource

I chose the Duck Simulator because it is a hands-on, practical example that clearly demonstrates OOP principles we are currently learning in class. I was looking for a resource that is engaging, easy to follow, and yet illustrates advanced programming concepts like abstraction, interfaces, and composition. The simulator is particularly appealing because it shows how separating behaviours from the main duck classes makes it easy to add new features or modify existing ones without rewriting the core code. This approach mirrors how professional software projects are structured, and I wanted to see an example that connects what we learn in theory to practical programming.

What I Learned and Reflected On

Working through the Duck Simulator helped me understand how to design flexible and maintainable code. Previously, I often relied on inheritance to share behaviours, but this project demonstrated how composition provides more adaptability and control. For example, I could give a Mallard duck a “fly with rocket” behaviour without touching the original class—something that would have been difficult or messy using only inheritance.

The project also helped me see the value of modular thinking, treating behaviours as separate, reusable components that can be mixed and matched across objects. This makes it much simpler to extend the program, add new duck types, or implement additional actions. Experimenting with the simulation gave me a tangible way to understand polymorphism and modular design, which made abstract class concepts from lectures much easier to grasp. It also reinforced the idea that writing clean, reusable code is as important as writing code that just works.

How I’ll Use This in the Future

In my future projects, I plan to apply the lessons from the Duck Simulator by designing programs in which behaviours can be swapped, updated, or extended independently of the main code. This will be especially useful in games, simulations, or any software where features may change over time. The project reinforced the importance of thinking ahead about software structure and planning for flexibility, rather than just focusing on making the code functional. Overall, the Duck Simulator showed me that good software design is a skill that complements programming ability, and it’s something I will carry forward in both my academic and professional projects.

From the blog CS@Worcester – Site Title by Yousef Hassan and used with permission of the author. All other rights reserved by the author.

Team management in software development

As a software developer there is a significant chance that you will develop software in a team environment. I know as an entry level developer gaining this experience beforehand would be a massive boost for my career but what exactly does team management entail?

The importance of team management

In a perfect world a team of developers all work perfectly together synchronously & complete a task in the best way possible. In reality, each team will have people of different skillsets, creativity, and ideas for development. Therefore, teams need to be managed in order to optimize development as much as possible.

Diagram illustrating the roles within a software project development team.

Creating a team

Before assembling a team for a project its important to highlight the scope & needs in order to figure out how many, and the type of, developers. According to itrex, some examples of developers you may need would be:

– Software Developer: Engineers and stabilizes the product & solves any technical problems emerging during the development lifecycle
– Software Architect: Designs a high-level software architecture, selects appropriate tools and platforms to implement the product vision, & sets up code quality standards and performs code reviews
– UI/UX Developer: Transforms a product vision into user-friendly designs & creates user journeys for the best user experience and highest conversion rates
– QA(quality assurance) Engineer: Makes sure an application performs according to requirements & spots functional and non-functional defects
-Test Automation Engineer: Designs a test automation ecosystem & writes and maintains test scripts for automated testing
– DevOps Engineer: Facilitates cooperation between development and operations teams & builds continuous integration and continuous delivery (CI/CD) pipelines for faster delivery
– Business Analyst: Understands customers business processes and translates business needs to requirements.
– Project Manager: Makes sure a product or its part is delivered on time and within budget & manages and motivates the software development team
– Project Owner: Holds responsibility for a product vision and evolution & makes sure the final product meets customer requirements

Infographic illustrating the challenges of managing software development teams, including communication, role clarity, and meeting deadlines.

Post-team assembly

Depending on your project you now have an idea on what team you have, the next step is actually managing them. This entails setting clear objectives/goals, creating a timeline, allocating resources, setting communication strategies, delegating, implementing, tracking progress, monitoring project, managing risks/challenges & maintaining flexibility.

Overview of a project manager’s essential roles and responsibilities in software development.

Final thoughts

I now have a better understanding the importance of team management in software development. In order to maximize efficiency towards a project/goal you definitely need to manage a significant amount of aspects related to development. The ability for a team to work together is also valuable & must be taken into account. Overall, I really enjoyed researching this topic, the main sources I used in my research was this section in Atlassians website as well as this section in the itrexgroup website.

, ,

From the blog Petraq Mele blog posts by Petraq Mele and used with permission of the author. All other rights reserved by the author.

The Value of Clean, Readable Code

Link to resource:
Why Clean Code is Important | The Power of Clean Code

While searching for a resource on software development and craftsmanship, I stumbled onto the article “The Clean Code Debate: Why Readable Code Still Wins.” It explores a long-standing debate among developers about the continued applicability of “clean code” the idea of writing code that is easy to read, understand, and maintain. In contemporary software development. Although frameworks and technology are developing quickly, the author argues that the ability to produce understandable codes that other developers can work with will always be necessary. The article discusses how techniques like consistent naming, few functions, and a clear structure lessen issues and promote collaboration, all while referencing Robert C. Martin’s Clean Code principles.

I choose this resource because I have noticed that a lot of programming projects and classes place more emphasis on getting the code to function than on making it readable or clean. I have come to understand the value of “maintainability” as I get ready to enter the workforce, not only for myself but also for everyone who might use my code in the future. The author made a particularly strong argument when she said that teams eventually get slower due to careless code. It brought back memories of collaborative projects where unclear variable names or a disorganized organization led to misunderstandings and more troubleshooting. I learned from reading this essay that producing “clean code” is about respecting future developers who will have to maintain or enhance the project, not only about style.

The essay taught me that the ideas of software architecture and design that we cover in CS-343 are directly supported by clean code. Writing code that is simple to modify and expand is related to ideas like modularity, separation of concerns, and readability. I too had to consider my own coding practices after reading the post. Although I occasionally shave corners to meet deadlines, this served as a reminder that little routines, such as explicitly naming functions or reworking when something seems too complicated, can add up to a significant impact over time. I intend to put these concepts into practice going forward by going over my assignments and side projects for readability and clarity rather than just functioning.

All things considered, this resource reaffirmed that “clean code” is a professional approach rather than merely an outdated notion. Great developers will always be defined by their ability to communicate through code, even when frameworks, languages, and tools change.

From the blog CS@Worcester – Life of Chris by Christian Oboh and used with permission of the author. All other rights reserved by the author.

Git bisect

In our class, in our latest POGIL we’ve started to explore debugging, an essential skill that uses different tests, tools, and commands.. The blog post “Supercharge Your Debugging with Git Bisect” by Phil Haack is a blog that talks about debugging with a tool that we’ve just started to familiarize ourselves with. That being git bisect, a command that helps developers locate the specific commit where a bug first appears. I chose this post because I was curious about how this tool can change debugging for me as a developer, as well as the idea of pinpointing where a bug starts in version control.

The post opens with a relatable story about the author facing a bug that had crept into his project over time. Instead of resorting to endlessly going through each commit and running tests, he turned to git bisect to efficiently find the problem. Haack explains how the command works like a binary search. It starts by marking a known commit where the bug exists and a known commit where the program worked correctly. Git then checks out a commit halfway between those two points. After testing that commit, the developer marks it as good or bad, and Git automatically cuts the range of possible culprits down until it pinpoints the exact commit where the issue began. Haack further elaborates on advanced features such as skipping commits that can’t be tested and automating the process with scripts through git bisect run. He also notes potential complications, like when the first bad commit is a merge rather than a single code change, which can make debugging a bit more complicated.

I chose this article because debugging is one my worst and most frustrating aspects of coding, and git bisect offers an easier approach that turns guessing into a faster, more efficient search. While I’ve used Git regularly for version control, I only recently realized it could actively help in finding bugs. The examples given in the blog made it easy to understand how bisecting commits can save on time, especially in large projects with long histories.

Reading this blog gave me new ideas about debugging. I’ve always viewed Git as a way to manage versions, especially when working with others, but now I see it as a debugging tool as well. The concept of using binary search to isolate problems makes me think about what other commands can be used to enhance my time when coding. It’s also a heads up that effective debugging depends on maintaining small, manageable commits because without manageable commits, even Git Bisect can struggle to pinpoint a specific change. Hopefully I can incorporate this tool into my workflow whenever I encounter bugs that I can’t find.

https://haacked.com/archive/2024/11/11/git-bisect/

From the blog CS@Worcester – Coding with Tai by Tai Nguyen and used with permission of the author. All other rights reserved by the author.

Blog Entry 2

Author: Yousef
Source:
Terra, John. AI for Project Management: Creating More Efficiency, Accuracy, and Better Results. UMass Global Blog, 2025.
https://bootcamp.umass.edu/blog/project-management/ai-for-project-management

Artificial Intelligence and the Future of Project Management

Artificial intelligence (AI) is rapidly transforming how organizations plan, execute, and evaluate projects. In his article, John Terra discusses the growing role of AI in automating processes that once required manual decision-making. He points out that AI technologies can analyze vast amounts of project data to identify trends, risks, and inefficiencies—long before human managers might notice them. This shift marks the beginning of a new era in project management, one where data and prediction take precedence over instinct and routine.

AI tools are now capable of predictive analytics, providing project leaders with accurate forecasts of timelines, costs, and potential risks. Terra also highlights emerging tools such as AI-driven chatbots that handle repetitive communications and machine learning models that track project performance in real time. These systems not only speed up workflow but also strengthen collaboration by giving every stakeholder access to transparent, centralized data. Importantly, Terra reminds readers that AI should complement not replace human judgment. Successful implementation still depends on leadership, empathy, and the ability to interpret data responsibly.

Why This Resource Stood Out

I was drawn to this article because it directly connects to the topics we have explored in Managing Information Systems specifically the use of technology to improve productivity, communication, and decision-making. As someone with a background in IT, I see AI as the next natural step in project management evolution. We already use tools such as GitHub and Trello to coordinate group work efficiently; AI takes this one step further by adding intelligence to those systems. Reading this piece helped me visualize how the principles we study in class can scale up to global business operations that depend on precise, data-driven project control.

Reflection and Application

Terra’s article expanded my understanding of what it means to manage projects effectively in the digital age. I learned that efficiency is not simply about speed it’s about designing systems that anticipate challenges before they occur. The idea of predictive risk management resonated strongly with me because it parallels what we strive for in software engineering: proactive problem-solving instead of reactive troubleshooting.

Another key takeaway was the emphasis on communication and ethics in using AI. Even the most advanced algorithms require human insight to ensure fairness, clarity, and accountability. As I advance in my career, I plan to explore AI-based project management tools and incorporate them into my workflow. This aligns perfectly with our program’s learning outcomes lifelong professional development and effective communication in both technical and managerial settings.

From the blog CS@Worcester – Site Title by Yousef Hassan and used with permission of the author. All other rights reserved by the author.

Bridging Structure and Flexibility: Understanding Software Design Methodologies and Agile

Hello everyone, and welcome to my blog entry for this week!For this week’s self-directed professional development, I explored the topic of Software Design Methodologies and Agile Practices. I used several online resources, including tutorials from Atlassian Agile Coach and readings from GeeksforGeeks. Even though the focus was on understanding Agile methodologies, I found that many of the ideas connected directly to our discussions in class about the software development life cycle (SDLC) and software design principles.

Summary of the Resource

Software design methodologies provide structured approaches to building and maintaining software systems. They define how development teams plan, design, implement, test, and deliver software. Traditional methodologies like the Waterfall Model, V-Model, and Spiral Model follow a sequential or plan-driven approach — where each stage must be completed before the next begins. These models emphasize documentation, predictability, and control.

On the other hand, Agile methodologies such as Scrum, Kanban, and Extreme Programming (XP) prioritize adaptability, collaboration, and continuous feedback. Agile breaks development into small iterations or “sprints,” allowing teams to quickly adjust to changes in requirements or user needs. Instead of rigidly following a plan, Agile embraces flexibility — delivering functional software early and improving it continuously.

The Agile Manifesto summarizes this philosophy in four values:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Why I Selected This Resource

I chose to focus on Agile methodologies because I wanted to understand how modern development teams manage complexity in real-world projects. We often hear about Agile in professional settings, but I wanted to explore why it has become so widely adopted. After learning about structured models like Waterfall, I was curious to see how Agile differs in terms of flexibility, teamwork, and iterative design.

This topic also connects closely to our class discussions on object-oriented design and project management, where adaptability and maintainability are key. Understanding these methodologies helps bridge the gap between theoretical design principles and practical implementation in team environments.

Personal Reflections: What I Learned and Connections to Class

Exploring Agile helped me see how methodology shapes not only the process but also the culture of software development. Here are a few takeaways that stood out to me:

  • Iteration mirrors refinement in design. Just like UML diagrams evolve as designs improve, Agile projects evolve through sprint cycles that incorporate feedback.
  • Communication is central. In Agile, daily stand-ups and retrospectives ensure the entire team stays aligned, similar to how collaboration in object-oriented design ensures consistent architecture.
  • Adaptability is a strength, not a weakness. While traditional models aim for stability, Agile embraces change — which is essential when building modern, user-driven applications.

In class, we often focus on designing systems that can evolve. Agile reinforces that same mindset at the project management level software design should anticipate growth, not resist it.

Application to Future Practice

Moving forward, I plan to apply Agile thinking to my future software projects, especially in group work or larger systems. Instead of trying to perfect a design from the start, I’ll focus on building incrementally, testing continuously, and welcoming feedback early in the process.

For example, in future programming projects, I could organize development into short milestones, use version control branches to represent sprints, and hold mini “retrospectives” after each stage. These habits will not only improve collaboration but also help me develop adaptable, high-quality code.

Citation / Link

Atlassian Agile Coach. “What is Agile?” Atlassian. Accessed October 2025. https://www.atlassian.com/agile
GeeksforGeeks. “Software Development Life Cycle (SDLC) and its Models.” 2025. https://www.geeksforgeeks.org

This exploration helped me connect the structured approaches of traditional methodologies with the flexibility and innovation of Agile. It reinforced that software design isn’t just about code — it’s about creating systems and processes that can evolve as technology and user needs change.

From the blog Rick’s Software Journal by RickDjouwe1 and used with permission of the author. All other rights reserved by the author.

From UML to Design Patterns: Refactoring the Duck Simulator

Hello everyone, welcome back to my blog! In my previous post, I explored object-oriented design basics and the importance of UML diagrams for understanding class relationships. This week, I applied that knowledge to a practical assignment by refactoring the Duck Simulator project using several design patterns, and I want to share what I learned from the process.

Introduction

UML diagrams provide a visual blueprint for software systems, helping developers understand relationships, dependencies, and responsibilities of different classes. While useful on their own, combining UML with design patterns allows us to translate those visual models into flexible, reusable, and maintainable code. In the Duck Simulator project, I used UML to identify repetitive behavior and then applied Strategy, Singleton, and Factory patterns to improve the system’s design.

Using UML to Identify Problems

Originally, the Duck Simulator consisted of an abstract Duck class and subclasses like MallardDuck, RedHeadDuck, RubberDuck, and DecoyDuck. Each duck implemented its own fly and quack methods. My UML class diagram made it clear that this design was repetitive: multiple subclasses had similar or identical behaviors. This repetition violates the DRY (Don’t Repeat Yourself) principle and makes the system harder to maintain or extend. The diagrams highlighted the exact areas where behavior abstraction could be applied, providing a clear roadmap for refactoring.

Applying the Strategy Pattern

The first refactor I implemented was the Strategy Pattern, which separates the fly and quack behaviors into FlyBehavior and QuackBehavior interfaces. Each duck is assigned a behavior object rather than hard-coding methods. Using UML, I could visualize how Duck classes now depend on behavior interfaces, not concrete implementations. For example, RubberDuck now uses the Squeak behavior, and DecoyDuck uses MuteQuack. This change made it easy to swap behaviors dynamically and reduced duplicated code across subclasses.

Using the Singleton Pattern

Next, I noticed that all ducks shared identical behaviors like FlyWithWings and Quack. To avoid creating multiple unnecessary instances, I applied the Singleton Pattern. UML helped illustrate that each behavior class has a static instance and a getInstance() method. This ensured that ducks reused the same behavior object, saving memory and improving consistency.

Implementing the Simple Factory Pattern

Finally, I created a DuckFactory to centralize the creation of ducks with their associated behaviors. UML shows a clear dependency from the simulator to the factory, encapsulating construction logic and removing manual behavior assignments in the simulator. This simplified code maintenance and improved readability, while maintaining all Strategy and Singleton benefits.

Reflection

This assignment reinforced how UML and design patterns complement each other. The diagrams helped me see problems in the design, and patterns provided proven solutions. After completing the refactor, the Duck Simulator is now modular, maintainable, and extensible. I can confidently add new duck types or behaviors without touching existing code. Personally, I learned that UML isn’t just documentation, it’s a tool that guides better design and code structure.

Resources

While exploring this assignment, I also reviewed a great resource that breaks down the concepts from Head First Design Patterns in a clear and structured way. You can find it here on GitHub. It helped me connect UML representations with real-world code implementations, especially when applying the Strategy Pattern in my Duck Simulator project.

From the blog CS@Worcester – Rick’s Software Journal by RickDjouwe1 and used with permission of the author. All other rights reserved by the author.