Category Archives: CS-348

Word wide outage

https://www.cnn.com/2025/10/25/tech/aws-outage-cause

The cloud AWS provider experienced a massive outage on oct 20, 2025 that shut down or impacted many of the most popular services and products on the internet like Roblox, and snapchat. The outage was so large many systems and product became unusable. This issue stemmed from a DNS issue where multiple automated systems were trying to update the same DNS entry which then threw a empty field. This empty field then was carried down to other services like EC2 which then caused those to fail and further down into other workflows and other systems that relied on services like EC2. Those failures carried down to Network balancers which essentially snowballed into a enormous mess that wrecked many apps and services. I personally clocked into work with our error handling system and alerts absolutely flooded will alarms and alerts. This became so bad my boss told me to just ignore the errors for the day (One of my sprint tasks is to keep alerts down). I chose this article due to its relevance to testing software and the probable use of git to find out when and where the error occurred. As the use of git bisect could be used to troubleshoot where the issue was introduced into the workflow to find out where the DNS field was assigned to two systems that could trigger at the same time. Furthermore AWS in their statement to the public states that “We know this event impacted many customers in significant ways, We will do everything we can to learn from this event and use it to improve our availability even further” This statement aligns with the values of scrum since it prioritizes openness and respect which AWS gives to its customers by openly documenting the issue that occurred while at the same time stressing the communication with the customers to reassure them in their recovery from the failure. They also follow the AGILE manifesto as they are responding to change over developing a plan since their customers need their services back now, prioritizing getting their services back online rather than documenting and collaborating with customers to have their systems restored. Delivering that they are only releasing their documentation once the system was fully restored under 15 hours showing that they needed to deliver on working software. In a way they could also be benefiting from focusing on individuals and interactions over tools since this error occurred at multiple levels but started at the same point so one tool or process couldn’t immediately understand the root cause.

From the blog CS@Worcester – Aidan's Cybersection by Aidan Novia and used with permission of the author. All other rights reserved by the author.

Quarter 2 Blog Post for CS-348

My chosen source for my 2nd blog entry for CS-348 is: https://www.sciencedirect.com/science/article/pii/S0950584922001884#abs0001

Written in 2023, this article from ScienceDirect surrounds a set of 182 survey’s conducted on scrum team members to determine the influence maturity has on the effectiveness and success of a scrum team and their project. The relevance to seem is fairly self evident as college students can be a mixture of mature and immature which the article suggests could impact effectiveness of scrum teams in the classroom.

This leads me onto why I chose this article as my source, In an environment like our classroom, the maturity of the students and or even professor(s) involved can, as said in the relevance portion, could impact our scrum team effectiveness and efficiency. I decided this was a strong connection to make as people new to the scrum framework, cause while understanding scrum and knowing how it works is important, I do think team member maturity is important as well as it has effected my ability to work in teams in the past and be effective and efficient.

I like that this article provides a good explanation of scrum and what it’s advantages are, it gives context for those unfamiliar with scrum to understand where the article is headed, although I would argue you don’t need the context as the study this article dives into can most certainly apply to any kind of framework out there. As for reflecting on this material I want to pull back to where I mentioned the maturity of my teams in past group projects and tasks have most certainly effected the ability of myself and my team to be effective and efficient at completing our goals, this is initially why this material called out to me as I read it. Though as I read it, I started to compare those experiences with what we’re doing in CS-348 currently. While not working in scrum teams, our teams of 4 for working on our class exercises to learn scrum are a good comparison towards maturity’s impact on our ability to finish the work in a reasonable amount of time.
For example, my first team, we were decently good at getting our work done in a good period of time, but I will admit sometimes we could be a bit slow as we let our maturity slip up. Once we mixed the teams around I saw how much more maturity mattered as we all adjusted to the effectiveness of all our new team members. Some teams got slower, some got faster, while I’m not pinning the reason entirely on maturity, I do think it’s a large influence. I also think its important that our teams got swapped around not just so we learned to work with new people but so we could learn to properly adjust and adapt to our changing environments.

From the blog CS@Worcester – Splaine CS Blog by Brady Splaine and used with permission of the author. All other rights reserved by the author.

Developing Teams: The Importance of a Strong Software Team

For this quarter’s blog post, I further explored the importance of developing a strong software team. The resource I chose is an article called “Better Software Engineering teams — Structures, roles, responsibilities and comparison with common approaches.” I chose this resource because it offers insights into how groups are organized for success, as well as the drawbacks of specific approaches that are used in current day. Building strong software development teams is a topic that ties directly into my current course, Software Process Management, discussions on team structures and project methodologies.

This article identifies and describes core characteristics of high-performing software engineering teams. It stresses the importance of traits like clearly defined roles, balanced seniority, responsibility and ownership, reasonable size teams, trust, transparency, strong leadership for effective team cohesion, executing and developing skills, to build and maintain a team environment of honesty and shared responsibility. 

This article strongly emphasizes the importance of having small and manageable sized teams, and provides a visual to better understand how bigger teams equal to higher chances of miscommunication and reduced efficiency.

Two common flawed approaches are analyzed (Single-Discipline Teams and Manager-Led Cross-Functional Teams) and compared to the optimal approach: Self-Managed Cross-Functional Team, via strong pros and cons lists. The key takeaway of this is to express that when team members understand their contributions to company and project goals, they are better equipped (with hard and soft-skills) to organize themselves and produce results efficiently.

This resource also reiterates the importance of team structure and team size, something of which I am directly experiencing within my POGIL-approach class, and class discussions on Agile and Scrum methodologies. This article provides the professional, industry-level validation for this very concept: the benefits of small, cross-functional groups for project completion.

My takeaway from this article is the benefits of self-managed cross-functional teams, and how unbalanced teams can lead to an increase of overworked members, lack of team cohesion, and decreased value and motivation into the project development and goal. Group work can be challenging, and even more so when the core values of a functional and strong team are absent. The article also emphasized the importance of strong leadership, as poor and ineffective leadership can be the root cause of common issues like “quiet quitting,” where team members feel the only way to bring attention to the poor leadership environment. This challenge is present, much too common, in fields outside of software development teams. 

As someone who sometimes struggles in team settings, due to worries about offering incorrect and simple input, I will make sure to understand the value I contribute to the team and not steer from contributing my knowledge. Even if my contributions are “simple” or “incorrect”, this will provide an opportunity to connect with and learn from my teammates, build an environment of trust and open communication, and strengthen my own leadership skills. As leadership does not start and end with the managers/leads of the team.

Main Resource:
https://medium.com/geekculture/better-software-engineering-teams-structures-roles-responsibilities-and-comparison-with-common-fb5c3161c13d – Better Software Engineering teams — Structures, roles, responsibilities and comparison with common approaches.

Additional Resources:
https://www.inc.com/peter-economy/why-quiet-quitting-is-actually-a-leadership-failure-and-how-to-fix-it/91181524 – Why Quiet Quitting Is Actually a Leadership Failure — and How to Fix It. Quiet quitting is a virus that affects entire organizations. Where it stems from might surprise you.

From the blog CS@Worcester – Vision Create Innovate by Elizabeth Baker and used with permission of the author. All other rights reserved by the author.

Types of Software Testing: Ensuring Quality in Development

Within the Software Development Lifecycle, it has a major step that takes a decent amount to do is Software testing. The purpose of software testing is that the program has no problems and meets the requirements set by the customer. Software development is divided into two different types: verification and validation. As noted before, verification is a step that has programmers checking if the software is doing as the customer intended. In the same vein, the validation step is just programmers testing if the software meets the customer’s requirements. For example a website wants to add a new feature to handle an increase of daily users on the platform. 

Moving on, there are multiple different types of testing programmers use to validate and verify if the program is working as intended. There is automation testing, and manual testing. They then divide into smaller more specific tests that will focus on certain aspects of the program. As mentioned earlier, automation testing is when programmers write test scripts with or without software and can run the tests repeatedly. While manual testing is a method of testing that has a programmer write tests that will check on different sections of the program.

Within software testing there are different levels of testing. They are called unit testing, integration testing, system testing, acceptance testing. 

Unit Testing

  • It is a testing that checks every component or software 
  • It is to make sure the hardware or software that could be used by the programmers 

Integration Testing 

  • It checks two or more modules which are tested are then put in the program or hardware 
  • To make sure the components and interface are working as intended

System Testing

  • Is a test that verifies the software itself 
  • Also it checks the system elements 
  • If the program meets the requirements of the system 

Acceptance Testing  

  • Validates if the program meets the customer’s expectation 
  • If the customer can work correctly on a user’s device 

These different types of testing are used to prevent issues down the line. So that programmers can find potential bugs, improve quality of the program, improve user experience, testing for scalability, also to save time and money. In order to save money and time because it takes a lot of employees to solve problems with a program that could have been used to make a new product. A business wants a program to work and be improved over time.

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

Scrum On

Software Development Methods

Wow, look at us, huh? Almost a month later, another post appears! This month (I guess I’ve moved to monthly blogging… We’ll tighten it up, I promise) has been mostly about the different ways to go about developing something. Neat, huh?

So far, we’ve talked about waterfall, agile, and the latest, scrum!

SCRUM

Scrum builds upon each previous development methodology, and is a natural extension of Agile. It is not, however, ‘better’ than agile, but simply different. No one methodology is the best, but some perform better than other in certain circumstances. Scrum is the latest methodology that my class has been learning about, and as such I decided to take some time to further look into it.

Scrum in 20 minutes is a video I came upon while looking for examples. It explains the process of scrum, why it is used, and how it is different to other methodologies. As well as this, the video contains a few examples of how using scrum has been beneficial.

One of the reasons that I decided to watch this video was that it simply looked professional. It was well polished, and felt like a finished product. A lot of the times, when I go looking for academic supplemental material, I’m presented with a sea of the same animated characters, slideshows, and whiteboard-style videos, so this one was a VERY nice change of pace. More of these, please! (I have some words with whoever invented PowToon).

This video really helped me to see how Scrum is applied to a real life example. I also appreciated the refresher on the process as a whole, but having real-life examples of a full sprint, planning, and what each of the team members’ roles contribute was really helpful in better understanding Scrum as a whole.

Something that I realized while watching the video, was that Scrum does not have to be software development specific. I play a lot of optimization games, and something like scrum just feels extremely organized, and is something that I feel is worth applying, at least in terms of concept, to more of my life than just this one small facet. Organization and goal setting is important in almost everything we do, and Scrum is just one way to do that, but it has been refined over multiple years of trial and error.

I am excited to apply scrum to future projects, and look forward to the increased organization that a solid planning methodology will bring to the table.

This concludes my mandatory blog post of Quarter 2 for the semester.

— Will Crosby

From the blog CS@Worcester – ELITE Computer Science by William Crosby and used with permission of the author. All other rights reserved by the author.

Understanding RESTful API design principles – Upsun Blog

This quarter I decided to read “Understanding RESTful API design principles” by the Upsun blog, which talks about many aspects of RESTful API. I picked this because it directly relates to what we’ve been learning recently in class, and relates to a system I will have to work with next semester for my Capstone. I figured it would be a good idea to get more familiar with REST API early.

The article starts off explaining what REST (REpresentational State Transfer) actually is. It’s a “set of architectural principles that define how to design and implement these interfaces”, discussing the HTTP methods involved. Being the only API design principle I know of, I had no frame of reference for its advantages compared to other options, but the article provides a chart and compares RESTful to GraphQL (good for more efficient and specific data fetching) and gRPC (Good for microservices and streaming).

The RESTful architecture typically contains a Client, Server, and Database, but it can include additional elements such as a load balancer or a cache. The Client, Server, and Database are fairly straightforward, being the consumer, the server hosting and processing the requests, and the database to store the data. The load balancer is also intuitive to it’s name, but for the smaller scale system like the Food Pantry which is unlikely to experience a large server load at any time anyway, it’s probably unnecessary.

The article goes into 6 design principles of REST APIs. The first one, Client-server architecture, states that the client and server should operate independently to make long-term maintainability better. The second is Stateless communication, stating that each request from the client should contain all the information needed to process the request. Nothing is stored on the server, so that each request is self-contained and can be handled independently, simplifying the process. The third is Cacheable Responses. If an API response is cacheable, it should include caching headers such as “Cache Control” or “Expires”, so that the data can actually be cached and the server doesn’t need to be queried every time. The fourth principle is Layered System. In many ways this seems similar to the principle of Abstraction, where the API should operate across multiple layers without the client being aware of the layers, reducing complexity and making it so the client doesn’t have to interact directly with multiple backend servers. The fifth is Uniform Interface, stating that the way resources are interacted with (ie. HTTP Methods, URL patterns, etc.) should be standardized and uniform. The last one is Code on Demand, which the article states as optional. It states that servers can use executable code such as Javascript to extend functionality.

Many of these principles were fairly intuitive, but it’s good to have them explicitly stated anyway. Some were also directly connected to our class discussions. Things like caching and the executable code stuff are things we didn’t talk about, but I’ll keep them in mind as we do more with REST API.

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

Why Software Maintenance Matters for Business Success

Recently AWS servers were not working due to something causing one third of the internet to go down. It made me start to think about what maintenance companies like Amazon have to have in order to make sure clients’ websites or programs do not get shut down. Then I found an article about Software maintenance explaining in a software engineer’s perspective on what happens with a product already made but has to be maintained. 

It starts to explain that software maintenance branches between bug fixes, adding new features, adding new hardware or software environments. At the end of the day the software has to work, be secure, efficient, and meet the users demands. As mentioned earlier there are multiple different types of software maintenance: bug fixes, patches, adaptive maintenance, optimizations, preventive maintenance. 

As programs get used or the amount of users start to increase companies have to consider that users might face bugs. These bugs can affect user experiences that might cause the company to lose a potential sale and even get bad reviews. These bugs can range from small coding errors or errors that might affect the user experience. 

In the future there is always the risk of needing to add patches to fix something very quickly. For example many companies would get hacked and have to undo the damage hackers might do to their program. Even though it could be an extreme case like getting hacked it could be a major update to the software that might be needed. 

Moving on to Adaptive Maintenance, it is about whether customers might want a new feature added to the software. Which could even change involving the environment, hardware, business wants, or new regulations that apply to the company. For example in the past the U.S government added a law to ensure the privacy of online users to prevent websites collecting data on users without consent.

Another type of maintenance is Perfective maintenance but to me I consider it optimizations. This can be either the consistency of the performance of a program and reliability. In addition, to make the software be flexible when adding new features or changes to it. 

The last type of Maintenance is Preventive maintenance. These could be features that make the program to be more secure, frequently tested, constant documents being made, and backups. This type of maintenance is to make sure potential problems can be fixed as quickly as possible and be tested so that it does not impact the user experience. 

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

REST API Design Practices

Link: https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/

In the blog post “Best practices for REST API design,” the authors go over important guidelines for designing any type of web service through the REST architecture style. They first go over the definition of a REST API, which is an interface that follows stateless communication and cacheability, as well as other constraints. They then show off a set of recommendations for good practices, such as using nouns and not verbs in endpoint paths, accepting and responding with JSON, logically nesting hierarchical resources, handling errors with standard HTTP status codes, and many more. The blog post emphasizes greatly that keeping names consistent and adhering to web standards will ultimately make APIs easier for maintainers and clients, as it will be easier for clients to use and maintainers to support. It would also make it much easier for systems to scale properly.

I selected this blog post because we are currently talking about this topic, and we have a homework assignment going over this topic so I thought it would be helpful to gain a deeper understanding of it. Also, in past courses, such as Unix Systems Programming, we would focus on architecture and backend systems, but I never really gave it a deeper look. This blog post gives very clear guidelines for REST API design, which can be very valuable in my career if I end up working in software or if I have to build or interact with APIs in the future. In the future, I plan on applying these principles if I ultimately have to design or integrate REST services, which could be through setting up a microservice in the cloud or even connecting to one as a consumer. I will definitely look to follow the guidelines listed in the blog post, as I believe that following those will provide a good baseline for my work. These API design patterns can also help me with projects, as I can ensure that my interface layers are clean and intuitive.

Overall, I thought that this blog post was very helpful and informative, as it provided a lot of clarity on the guidelines for REST API design. Their point about using nouns in endpoint paths was a very good point, as it is better for HTTP verbs to be doing the action. While it is a small naming decision, it can end up making a big difference when it comes to readability and maintainability. In the end, this blog post improved my understanding of REST API design practices and showed me that good design isn’t just about the efficiency of the algorithms and resources, but it is also about the service and client experience.

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

Understanding Scrum

My understanding of Scrum is that it isn’t just a process or checklist; it’s a lightweight framework for solving complex problems through collaboration, transparency, and continuous improvement. The Scrum Guide defines Scrum as: “a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.” The framework is based on … Read more

From the blog CS@Worcester – BforBuild by Johnson K and used with permission of the author. All other rights reserved by the author.

BLOG 2 – Agile vs Scrum

There are many different methodologies that can be used for project management. The two that I would like the most are Agile methodology and Scrum methodology. So, what are the differences between these two methodologies, and when is choosing the right one? In this article, I want to summarize the key differences between agile and Scrum methodologies based on what I just read from Northeastern University Graduate Programs. Their article is really helpful for me and you to understand what they are and their differences. The article link is posted below. Feel free to check it out for further information: 

Agile vs. Scrum: What’s the Difference?

Agile vs. Scrum: What’s the Difference?

By Shayna Jouber

What is Agile Project Management? 

People say that Agile is a way of thinking about project management that focuses on delivering in small steps, being in touch with customers, and being able to adapt to change. Agile doesn’t tell you what process to use; instead, it gives you ideals and principles (like those in the Agile Manifesto) that you may use with other methods (like Scrum, Kanban, XP, etc.).\

Important traits: constant communication with customers and end users, willingness to change the scope of work, and delivering work in small steps.

What is Scrum Project Management?

One such approach in the Agile family is Scrum. It offers a clear procedure for handling tasks, including who completes them, how they are arranged, and when they are finished.

Typical Scrum responsibilities include a cross-functional team, a product owner who is in charge of optimizing the product’s value, and a scrum master who makes sure the team follows Scrum procedures.

Work is divided into sprints, which typically last two to four weeks. The team decides which subset of the scope to finish at a sprint planning meeting. Every sprint concludes with a review and retrospective to consider what was accomplished and make improvements.

Frequent delivery of “shippable” increments as opposed to waiting until the project is finished to provide everything is one of the clear benefits.

Agile vs Scrum – Key differences 

Agile is the underlying idea or strategy, and Scrum is a way to put Agile into practice.

Scrum is always Agile since it adheres to Agile principles, but utilizing Agile does not imply using Scrum; you may choose to use another Agile methodology instead.

Choosing the Right Methodology 

  • Agile: Agile makes sense if the project requires flexibility, frequent testing, stakeholder feedback, and shifting requirements.
  • Scrum: Scrum usually works well in situations with a lot of uncertainty, rapid changes, and the ability to arrange into sprint cycles.

Selecting the approach is only one aspect of it; another is having strong communication, leadership, critical thinking, project management, and organizational dynamics skills.

Conclusion 

Don’t use “Agile” and “Scrum” interchangeably; Agile is more comprehensive, and Scrum is one way to achieve it.

Before choosing Agile, consider the context of your project; if you decide on Agile, select the appropriate approach.

Methodology is only one aspect of successful project management; other factors include teamwork, stakeholder engagement, effective leadership, and flexibility.

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