Category Archives: Week 9

Is Agile going to fail?

 

This article by
Jeff Gothelf asks the question “Is Agile finally over?” after 20+ years of
implementation to tech field. He argues that even though Agile’s widespread
adaptation hasn’t got the result that Agile was intended for. Many companies
claimed to be “Agile” as they copy each other, but the implementation of it was
shallow or almost non-existent to make changes according to it. Therefore, he
says that agile does not seems working as companies try to make employee follow
set of rules instead of working in following the basic principles of Agile. He
concluded that organizations need to focus on true organizational agility
rather than rigid framework adoption.

This article
caught my attention while searching through the internet as it criticizes Agile’s
current status in the business world as ideal of agile does not really fit in
reality in organization experience. The vague promises and core ideas are often
overlooked to the ‘wants’ of either customer or the organization. The output is
never about efficient program but a program that works made in short amount
time. In the end, it feels like the organization’s internal culture and goals
must align with the methods it adopts to fully be efficient which does not seem
to work for a lot of groups that ‘follows’ agile. Learning that to me, teamwork
following agile principle is hard from top-down management as they try to
follow rules made by the organization to follow the given framework, that is
why agile is not working for many in my opinion.

This got me to
reflect that to practice agile in the future, that I need to try to make sure
that if the company says they do ‘agile’ format for development, I need to check
with others so that if they want ‘agile’ following company standard or the real
agile that I learned in class. I feel like this way even more because when I work
at a part time job, company wanted to follow xyz because and it was annoying
and required lot of process which contradicted for the speed of work they
wanted us to work on. Therefore, no one really followed by the book or the procedures
were implemented shallow, so it was not effective at all, I think this was the same
case for agile in the long run. It feels like agile manifesto was built for
small teams or companies where they could discuss things multiple times in
small groups not to be used by large companies as it will be always shallow or
just another term to company’s rules to schedule how work is done. Therefore, I
feel like widespread use of agile is dying down unlike what the author says
because no one tries to keep that rule in big companies. 

 

https://jeffgothelf.com/blog/is-agile-over/

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

Is Agile going to fail?

 

This article by
Jeff Gothelf asks the question “Is Agile finally over?” after 20+ years of
implementation to tech field. He argues that even though Agile’s widespread
adaptation hasn’t got the result that Agile was intended for. Many companies
claimed to be “Agile” as they copy each other, but the implementation of it was
shallow or almost non-existent to make changes according to it. Therefore, he
says that agile does not seems working as companies try to make employee follow
set of rules instead of working in following the basic principles of Agile. He
concluded that organizations need to focus on true organizational agility
rather than rigid framework adoption.

This article
caught my attention while searching through the internet as it criticizes Agile’s
current status in the business world as ideal of agile does not really fit in
reality in organization experience. The vague promises and core ideas are often
overlooked to the ‘wants’ of either customer or the organization. The output is
never about efficient program but a program that works made in short amount
time. In the end, it feels like the organization’s internal culture and goals
must align with the methods it adopts to fully be efficient which does not seem
to work for a lot of groups that ‘follows’ agile. Learning that to me, teamwork
following agile principle is hard from top-down management as they try to
follow rules made by the organization to follow the given framework, that is
why agile is not working for many in my opinion.

This got me to
reflect that to practice agile in the future, that I need to try to make sure
that if the company says they do ‘agile’ format for development, I need to check
with others so that if they want ‘agile’ following company standard or the real
agile that I learned in class. I feel like this way even more because when I work
at a part time job, company wanted to follow xyz because and it was annoying
and required lot of process which contradicted for the speed of work they
wanted us to work on. Therefore, no one really followed by the book or the procedures
were implemented shallow, so it was not effective at all, I think this was the same
case for agile in the long run. It feels like agile manifesto was built for
small teams or companies where they could discuss things multiple times in
small groups not to be used by large companies as it will be always shallow or
just another term to company’s rules to schedule how work is done. Therefore, I
feel like widespread use of agile is dying down unlike what the author says
because no one tries to keep that rule in big companies. 

 

https://jeffgothelf.com/blog/is-agile-over/

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

Is Agile going to fail?

 

This article by
Jeff Gothelf asks the question “Is Agile finally over?” after 20+ years of
implementation to tech field. He argues that even though Agile’s widespread
adaptation hasn’t got the result that Agile was intended for. Many companies
claimed to be “Agile” as they copy each other, but the implementation of it was
shallow or almost non-existent to make changes according to it. Therefore, he
says that agile does not seems working as companies try to make employee follow
set of rules instead of working in following the basic principles of Agile. He
concluded that organizations need to focus on true organizational agility
rather than rigid framework adoption.

This article
caught my attention while searching through the internet as it criticizes Agile’s
current status in the business world as ideal of agile does not really fit in
reality in organization experience. The vague promises and core ideas are often
overlooked to the ‘wants’ of either customer or the organization. The output is
never about efficient program but a program that works made in short amount
time. In the end, it feels like the organization’s internal culture and goals
must align with the methods it adopts to fully be efficient which does not seem
to work for a lot of groups that ‘follows’ agile. Learning that to me, teamwork
following agile principle is hard from top-down management as they try to
follow rules made by the organization to follow the given framework, that is
why agile is not working for many in my opinion.

This got me to
reflect that to practice agile in the future, that I need to try to make sure
that if the company says they do ‘agile’ format for development, I need to check
with others so that if they want ‘agile’ following company standard or the real
agile that I learned in class. I feel like this way even more because when I work
at a part time job, company wanted to follow xyz because and it was annoying
and required lot of process which contradicted for the speed of work they
wanted us to work on. Therefore, no one really followed by the book or the procedures
were implemented shallow, so it was not effective at all, I think this was the same
case for agile in the long run. It feels like agile manifesto was built for
small teams or companies where they could discuss things multiple times in
small groups not to be used by large companies as it will be always shallow or
just another term to company’s rules to schedule how work is done. Therefore, I
feel like widespread use of agile is dying down unlike what the author says
because no one tries to keep that rule in big companies. 

 

https://jeffgothelf.com/blog/is-agile-over/

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

Is Agile going to fail?

 

This article by
Jeff Gothelf asks the question “Is Agile finally over?” after 20+ years of
implementation to tech field. He argues that even though Agile’s widespread
adaptation hasn’t got the result that Agile was intended for. Many companies
claimed to be “Agile” as they copy each other, but the implementation of it was
shallow or almost non-existent to make changes according to it. Therefore, he
says that agile does not seems working as companies try to make employee follow
set of rules instead of working in following the basic principles of Agile. He
concluded that organizations need to focus on true organizational agility
rather than rigid framework adoption.

This article
caught my attention while searching through the internet as it criticizes Agile’s
current status in the business world as ideal of agile does not really fit in
reality in organization experience. The vague promises and core ideas are often
overlooked to the ‘wants’ of either customer or the organization. The output is
never about efficient program but a program that works made in short amount
time. In the end, it feels like the organization’s internal culture and goals
must align with the methods it adopts to fully be efficient which does not seem
to work for a lot of groups that ‘follows’ agile. Learning that to me, teamwork
following agile principle is hard from top-down management as they try to
follow rules made by the organization to follow the given framework, that is
why agile is not working for many in my opinion.

This got me to
reflect that to practice agile in the future, that I need to try to make sure
that if the company says they do ‘agile’ format for development, I need to check
with others so that if they want ‘agile’ following company standard or the real
agile that I learned in class. I feel like this way even more because when I work
at a part time job, company wanted to follow xyz because and it was annoying
and required lot of process which contradicted for the speed of work they
wanted us to work on. Therefore, no one really followed by the book or the procedures
were implemented shallow, so it was not effective at all, I think this was the same
case for agile in the long run. It feels like agile manifesto was built for
small teams or companies where they could discuss things multiple times in
small groups not to be used by large companies as it will be always shallow or
just another term to company’s rules to schedule how work is done. Therefore, I
feel like widespread use of agile is dying down unlike what the author says
because no one tries to keep that rule in big companies. 

 

https://jeffgothelf.com/blog/is-agile-over/

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

Best Free Project Management Tools in 2025 – A Quick Rundown

This week, while looking for blog posts to write about, I came across an article by Kiera Abbamonte on the Zapier blog called “The Best Free Project Management Software in 2025.” Kiera’s article dives into eight top project management tools that are totally free and packed with features for task management, collaboration, and keeping things productive. Zapier really went all out testing each one, breaking down what each tool does best. It’s a great find if you’re trying to manage projects without spending a ton.

Kiera starts off by explaining that while some people manage fine with just a to-do list or calendar, teams usually need more structured tools to keep everyone on the same page. When you’re working with others, it’s important to have ways to track tasks, communicate easily, and stay organized. Her list includes some well-known options, like Trello, which is big on visual task organization, and Asana, which focuses on teamwork. She also mentions tools like ClickUp for flexible task views and Airtable for custom workflows. For developers, Jira is recommended because it’s designed with Agile in mind, and Height even has some AI features for automating repetitive tasks. Finally, there’s Paymo, which is especially helpful for freelancers since it includes time tracking and invoicing all in one place.

I chose this article because it lines up well with what we’re learning about project management. It doesn’t just list a bunch of apps; it actually dives into why certain features—like flexibility, integrations, and collaboration tools—matter. Kiera does a great job highlighting the pros and cons, which helped me think about what I’d really want in a project management tool. It also got me thinking about how each tool might suit different types of projects.

After reading, I feel like I have a better sense of how the right project management setup can make a difference, especially for group projects. Trello’s visual boards, for example, seem like a simple, flexible way to keep tasks organized, whether it’s for personal projects or something with a team. Asana’s team-focused features make me realize how much clear task assignments and easy communication can help everyone stay on track. This article has definitely given me a few ideas on organizing future group projects to keep things moving smoothly.

If you’re curious about free project management tools, I’d definitely recommend checking out this article. It’s a practical guide for anyone looking to get organized without spending a fortune, and Kiera’s insights make it easy to see which tools might fit best based on your project needs.

Link to the post: The Best Free Project Management Software in 2025

From the blog CS@Worcester – Harley Philippe's Tech Journal by Harley Philippe and used with permission of the author. All other rights reserved by the author.

Project Management

Source: https://monday.com/blog/project-management/guide-to-project-management/

The title of this blog is “What is Project Management? The Complete Guide [2024].” As seen from the title, this blog obviously describes the ins-and-outs of project management. The idea of project management is to manage projects by ensuring that they are delivered on time, within a set budget, and satisfy the needs of the stakeholders. Project management involves setting goals, scheduling, managing, monitoring, and collaboration. This is accomplished through various methodologies such as Agile, Kanban, or Scrum. This is an important field, and topic, because teams of individuals are the ones who provide the greatest projects and products to the market, and without effective leadership and problem solving, they would never come into fruition. Many different organizations employ project managers, ranging from small businesses to Fortune 500 companies. Project management is not exclusive to software engineering though, it can be seen in other sectors such as construction or marketing. “The Project Management Body of Knowledge (PMBOK Guide) defines ten key project management knowledge areas” them being: scope management, schedule management, procurement management, stakeholder management, risk management, communications management, resource management, quality management, cost management, and integration management. These are all self-explanatory from their names but are very important for being an efficient and effective project manager. There are many different tools used in this field, such as Gantt charts (used for scheduling and tracking tasks in a visual timeline), tasks lists, Kanban boards, calendars, budget trackers, mobile apps, and many others. One might ask if a project is completed and another one is about to be started, is everything created from scratch? The answer is no. Project managers use templates to fill in instructions from prior work to save time when initiating a new project. There are quite a few roles in project management, one being the project manager themself, the project sponsor, the team members, the stakeholders, the customer, the office, and the steering committee (who provides oversight). All of these individuals make the creation of projects operate smoothly.

I chose this particular post about project management because it appeared to be all-encompassing of the topic, and I was correct. After learning about Agile and Scrum methodologies in class, I was interested in learning about the importance of having a project manager in various sized companies. I can appreciate the fact that they have to communicate with stakeholders, engineers, and management in order to ensure smooth operation. Overall this material was very interesting to me because I’ve had an interest in this field for my future career. If I end up pursuing project management, this information would definitely be beneficial for performing my job appropriately. If I don’t, knowing the role of a project manager would be beneficial regardless because I’m bound to work with one regardless. Having an understanding of your coworkers’ roles at your company is important for collaboration. 

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

GRASP

Source: https://www.youtube.com/watch?v=GcqTrlL_Htw

This video from YouTube is titled “Design Patterns GRASP // Object Oriented Analysis and Design (ICS).” As stated in the title, it goes over the design patterns of GRASP, or General Responsibility Assignment Software Patterns. GRASP is a set of 9 principles that relate to object-oriented design that help developers/engineers assign certain responsibilities to certain variables, classes, objects, etc. in software. The overall purpose of GRASP isn’t to create “fancy” code, but rather to create maintainable and reusable code/software. The 9 principles are information expert, creator, controller, low coupling, high cohesion, polymorphism, pure fabrication, indirection, and protected variations. “Information expert” places responsibility on classes that have the required information to complete it, wanted behaviors and data are put together. “Creator” places responsibility for the creation of instances of classes to classes that would use it. “Controller” places responsibility for handling system events to a class that describes the event, known as the controller. “Low coupling” states that classes should be as independent as they can be from other classes. “High cohesion” states that classes should have clear purposes with responsibilities that relate to it. “Polymorphism” is implemented so new behaviors can be added without changing preexisting code. “Pure fabrication” states that new classes should be created if there isn’t an already existing one that fulfills a desired requirement. “Indirection” states that dependencies among classes should be minimized so changes can be made without having an impact on other parts of the system. Lastly, “protected variations” encourages developers to design the system in a way that variations in behaviors are negated through encapsulation. 

I chose this particular source because we haven’t covered this topic in class yet and it seemed interesting, I found the topic from the syllabus. This video had a low amount of views and I wanted to give it a chance. After watching the video, I appreciated the fact that the information was presented in a straightforward manner and offered visual examples for each of the 9 principles of GRASP. After learning about Agile methodologies, it was interesting to learn about GRASP, because in my opinion it seems as though instead of being a set of principles of workplace improvement, GRASP seems to be a set of principles for actual work improvement. Overall, the material impacted me in a positive way because I appreciate the idea of everything in a system/software having a certain responsibility, and can definitely see how this will benefit me in the future when I work on more projects related to software development. I will certainly keep GRASP in mind for these future projects. 

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

Design Patterns

A good programmer and software developer will create code and software that is easy to maintain and modify. When problems arise, issues could be taken care of fairly easily. But sometimes, the easiest solutions are not the best ones, it could make the software more difficult to maintain or change. Using design patterns can help identify these issues and show some solutions to those issues. 

In class, we worked with a few design patterns, specifically the strategy design pattern, the singleton, and the simple factory pattern. Each one does something a little different from each other, but they help make things organized in a sense. We used them all together, implementing each one by one, but each could be used separately.

In this blog post, Giridhar Talla writes about design patterns, and describes them as an “existing solution.” They define design patterns as “solutions to commonly occurring design problems in developing flexible software using object-oriented programming.” Design patterns can vary, and can be grouped into 3 groups, creational patterns, creating objects to increase code flexibility and reuse, structural patterns, turning relations between objects and classes into complex structures, and behavioral patterns, defining how objects communicate with another. The specific design patterns Talla goes over are the singleton design pattern, the decorator design pattern, the strategy design pattern, the state design pattern, and the command design pattern. Each pattern is unique in its own way, flexible and simple. After reading, I found the state design principle very interesting. Instead of a lot of conditional statements, you could create multiple states. The user can change how the application works at runtime, which allows you to design finite state machines. I find this cool and unique, as it is something I have not personally done, but the concept seems really interesting.

A good programmer should be able to create reusable and extendable code, it is just good practice. Design patterns can help you make them flexible and maintainable. I chose this blog post because I thought design patterns were really useful and interesting, and I wanted to learn more about other kinds of patterns. Since design patterns are somewhat recognizable due to their reuse, it is not hard to explain unseen software to people who have not looked at it before. Even if it is done wrong, it will help you or a team understand what is wrong with the overall thing, and then from there, you can apply the correct one. I am fairly certain that I will be using these in the future.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

Learning from Git Mistakes

This week, I explored the blog post “Rebasing: What Can Go Wrong?” by Jessica Rose, a software engineer who delves into the potential pitfalls of using Git’s rebase command. In class, we use Git extensively, which made this post especially relevant. Rose provides a detailed explanation of rebase, a tool used in Git for streamlining commit histories. While it can be incredibly powerful, Rose emphasizes that it’s easy to make mistakes that can lead to confusion, conflicts, or even the loss of code changes.

The blog post highlights several common issues developers may encounter while using rebase, such as accidentally overwriting commits, losing track of the original branch history, or making errors when dealing with merge conflicts. Rose walks the reader through how to prevent these issues, offering advice like creating backups before rebasing and using interactive rebase for a more controlled process. She also provides helpful tips for handling conflicts during the rebase, stressing the importance of careful attention to detail and understanding the consequences of each decision made during the process.

I chose this blog post because it directly relates to our class’s frequent use of Git. Git is a powerful version control system that helps manage code, but as we work with it, we often encounter challenges in mastering commands like rebase. Understanding the nuances of rebase can help avoid the frustrations that come with making mistakes in a shared repository. This post offered practical insights into some of those mistakes, providing guidance on how to handle them more effectively.

What stood out to me the most was how Rose emphasized the importance of understanding what’s happening at each step of the rebase process. It’s not just about executing commands but also being aware of the impact on the entire commit history and potential conflicts. I found this especially helpful, as I’ve been guilty of rushing through Git commands without fully grasping their implications. The blog helped me realize that, even with powerful tools like rebase, the key is taking time to understand the underlying mechanics and risks involved.

The material from this post will certainly influence how I approach Git in the future. I now feel more confident using rebase, knowing that I should always create backups before rebasing and be mindful of merge conflicts. In future collaborative projects, I’ll make sure to use interactive rebase more carefully, ensuring I don’t overwrite commits unintentionally. Additionally, I’ll aim to avoid common mistakes like rewriting history that others depend on.

Overall, Rose’s blog provides an insightful and practical guide to understanding rebase and avoiding its common pitfalls. For anyone who works with Git or is learning it, I highly recommend reading the post to better understand the potential risks and how to manage them effectively. It’s a perfect resource for improving Git workflows and ensuring smoother collaboration in teams.https://jvns.ca/blog/2023/11/06/rebasing-what-can-go-wrong-/

From the blog CS@Worcester – CS Journal by Alivia Glynn and used with permission of the author. All other rights reserved by the author.

Coding Standards with Generative AI

https://www.blackduck.com/blog/generative-ai-risks-in-software.html

This blog posts discusses the issues that AI generated code causes for licensing caused by the use of proprietary code in model training, and issues for coding standards caused by the varying quality of AI code. I chose to look at this blog because I know many of my peers, including myself, occasional use AI to generate code for debugging and for small chunks of code that they don’t feel like making on their own for the sake of efficiency. Even in these small cases, we run the risks proposed by the blog.
Reading this blog made me reflect on how I use AI in my own coding, especially as it relates to coding standards. Typically I use it for debugging, which really means the only thing I need to concern myself with is making sure I understand the adjusted code and it follows the same formatting I used. However, this has affected my thoughts about using AI for small snippets that would be more efficiently written with AI. Upon reflection with the article, it made me realize the reason we allow AI to write code, is the same reasons we always write bad code; we just want to get it done. The most interesting part is, it also has the same consequences as just rushing to get it done. There have been a handful of times when I’ve been looking at a peer’s code, and it did something I thought was quite impressive, then I went to ask them about the functionality of it, but they were unable to do the fact that they were not the ones who actually wrote the code I was interested in, and it was so abstracted that they themselves did not really understand it.
I will admit I’ve had similar things happen before. For example, there was one time when I was working on a project, and there was a method I had to write that was very annoying. So I asked an AI to write it for me so I could move on with my project unannoyed. The code it wrote functioned in the tests I gave it, and it was even formatted correctly, it also had comments that describe what it was doing. Later on in the project I was getting very ludicrous results, and I had no idea why. After a while, I went back to the code and realized, the comments it wrote basically just recited the prompt I gave it, and did not actually describe what it was doing. After making attempts at fixing it, I ultimately had to completely rewrite the method on my own, wasting much of my time. My experiences as well as this article have allowed me to realize just how important writing clean, and understandable code is, and why we should avoid trying to cut corners on our projects even if it seemingly save us time. It is far more important to make good code at an efficient, than generate functioning code at a fast pace.

From the blog CS@Worcester – CS ZStomski by Zachary Stomski and used with permission of the author. All other rights reserved by the author.