This article is a beginning-to-end write up of the Agile methodology by Miriam Posner, an Assistant Professor at UCLA. She starts with a pov of someone watching an agile team in action, complete with all the user stories, story points, stand ups, a whiteboard, post-it notes, and sprints. For those who have not been introduced to this software development process, ‘stories’ are descriptions of features with ‘points’ showing the difficulty of implementing said features. ‘Stand ups’ are start-of-the-day meetings done standing up for quickness, the whiteboard is to organize each story point, represented by post-it notes, into the stages of ‘in-progress’, ‘done’, ‘backlog’, etc. ‘Sprints are just quick two week long work periods that help to break down the project into digestible chunks.

While this might seem rather much from to some people, others might have an opinion closer to Miriam, who found it to be efficient and intriguing. As such she researched the origins of Agile and learned the complicated history of managers and software developers. I will try to keep this summary brief while hitting all the major points.

Miriam starts with the buildup to Agile. It started in the 50’s and 60’s, most ‘experts’ said building the computer was the hard part and programming it would be trivial. The sheer enormity of their incorrectness led to a push in the field to adopt the name (and stricter processes) of engineering, leading to the coining of the term ‘software engineering’. The idea was that by following engineering techniques the experts would “transform the arcane and error-prone craft of computer programming to meet the highest standards of the engineering profession.” The next people to step in were the businesses who looked to hire these new ‘software engineers’. They created a framework of control where one person defines the project and breaks it up into steps, which are in turn handed to engineers to build and test before moving on to the next step. This was derogatorily called the “waterfall” method, so of course upper management took the name and method and ran with it. This method started to fail due again to people who were not programmers believing they knew what programming entailed. The main problem was that whenever any issue came up in the code, every step needed to be redone which meant the timeline would be increasingly muddled.

Next came Agile, created by “17 middle-aged white guys dressed in khakis and dad jeans” in the Agile Manifesto. In their words:
“We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.“

I would like to continue this dive but I am out of words.

Have a good day.

Link:
https://logicmag.io/clouds/agile-and-the-long-crisis-of-software/

From the blog CS@Worcester – Coder's First Steps by amoulton2 and used with permission of the author. All other rights reserved by the author.

Hello everyone

For my last blog for the semester, the topic would be about Software Licenses and their importance in the computer science field. This was one of the most underrated things I learnt during the semester, so that’s why I wanna talk about it. Even though now it seems obvious, it never crossed my mind that I should always put a license on my project. This blog makes an amazing explanation on why you should always put a license on your work and also which one to choose from.

The blog begins by explaining the different types of software licenses, starting with:        Permissive Licenses – which impose minimal restrictions on what you can do like modification and distribution of it. Some of the most popular permissive licenses are the MIT and the Apache license. They are highly popular because they typically only require attribution, which is that you have to give credit to the original author.                                            Then the blog talks about:                                                                           Copyleft Licenses – anyone could modify and distribute the code, but they had to share their changes with the community under the same license. Some of the most popular Copyleft Licenses are the GNU Lesser General Public License (LGPL), which allow linking to open-source libraries with limited obligations but impose stricter requirements if the library is modified. There is also the GNU General Public License (GPL). They are a bit more restrictive, requiring that any derivative works be distributed under the same license and with access to the source code.                                                               

At the end of the blog, it addresses unlicensed code. Emphasizing that code without a clear license is not automatically free to use and may lead to copyright infringement. If the code does not have a license then it is considered to be under the default  copyright laws. This means that only the original author has the right to use, distribute or modify it. If someone was to happen to use it even if it is publicly available, it raises legal issues.          This blog to me was incredibly helpful and useful as it not only explained the various types of software licenses but also gave examples of them. It showed and highlighted the types of works and where would you wanna use these licenses and what works the best for you. One thing that I learnt while reading this blog was understanding what is an SBOM which stands for Software Bill of Materials. It is a detailed list of all the components in the code and their respective licenses. It is important to understand what licenses works the best for you so you can get the most out of it. The computer science field is an amazing work space that everyone can work together to build each other up and licenses help us do just that!

https://www.blackduck.com/blog/5-types-of-software-licenses-you-need-to-understand.html

From the blog CS@Worcester – Elio's Blog by Elio Ngjelo and used with permission of the author. All other rights reserved by the author.

I recently read the article “Gathering Requirements for a Development Project in 2025” on Developer-Tech.com. The article talks about how collecting and understanding software requirements is changing, focusing on new technologies and ways of working to make the process better.

I picked this article because I want to improve how I manage software projects. Gathering requirements is such an important part of any project, and understanding future trends can help me stay ahead. The article gave clear examples of how requirement gathering is improving and what to expect in the coming years.

The article covered three key points:

• Using Artificial Intelligence (AI): It explains how AI tools can make collecting and understanding requirements faster and more accurate. AI can analyze a lot of data quickly and help figure out what stakeholders (the people involved in the project) need.
• Better Team Collaboration: The article emphasizes how important teamwork is. New communication tools are helping teams work together more easily, making sure everyone understands the project’s goals.
• Agile Development Methods: It talks about Agile, a way of working that breaks projects into smaller steps. Agile lets teams adjust requirements as they go, so the final product meets user needs better.

This article made me think differently about how I collect and organize project requirements. The idea of using AI tools stood out to me because it would make the process quicker and catch mistakes I might miss. In the past, I’ve done everything manually, and it can take a lot of time.

The part about teamwork also hit home for me. I’ve worked on projects where poor communication caused delays and confusion. Using tools that help everyone stay connected and clear about the goals can make a big difference.

I also liked what the article said about Agile. I’ve worked on projects where requirements changed halfway through, and it was stressful. Agile makes it easier to handle those changes, which is something I plan to learn more about and use in future projects.

Overall, this article was a great introduction to how requirement gathering is improving. By using AI, working more closely with teams, and adopting Agile methods, I can do a better job on projects. If you’re interested, I recommend reading the full article: Gathering Requirements for a Development Project in 2025.

From the blog CS@Worcester – Zacharys Computer Science Blog by Zachary Kimball and used with permission of the author. All other rights reserved by the author.

I’m writing this blogpost about Scrum, specifically about the Sprint Retrospective(although the author refers to it as a Scrum Retrospective) that takes place after a Sprint Review. This blogpost(possibly article?) caught my eye while I was browsing through some blogs, as it directly references something we’ve learned about in class, but from a different point of view. Does ‘fun’ and ‘silliness’ have a place in a professional setting like a Sprint Retrospective? My initial thought after reading this introductory question is that yes, a little playfulness is fine as a means to relieve tension and stress, so long as it doesn’t hinder productivity, and so long as everyone is comfortable with it. But while it’s fine in moderation, it’s by no means a necessity. If someone wants to maintain professionalism, then that’s completely fine too. But as someone who’s never actually worked on a development team, I was interested to hear an experienced person’s take on the subject.

In the referenced article, Sjoerd Nijland first addresses the common critiques of playfulness, where people call it unserious and unprofessional, and assume that it gets in the way of productivity. He counters by mentioning the benefits of playfulness based on neuroscience. Some of these include: Improving brain function, energy, and happiness, relieving stress, deepens connections and trust, and encourages creativity needed for problem-solving, amongst many other benefits. It’s something that everyone, even introverts, can benefit from. It’s a mindset. It provides psychological safety. It puts people in a comfort zone, leaving them open to new ideas and discussion. It keeps people trusting of one another, instead of checking and inspecting each other. And so he counters the common by saying that not only can it be beneficial in a professional environment, but that “Discouraging playfulness at work is profoundly UNprofessional”. When applied intentionally, it can be a great mechanism for helping your team deal with what would otherwise be a stressful environment.

I like the way he views playfulness, because he thinks of it in a different way than most people would. Playfulness isn’t slacking, it’s a tool, one that benefits team dynamic and productivity in the long run. Too much of it can be detrimental, and people shouldn’t be neglecting work for play, but ideally it should exist in some capacity. He references existing scrum environments and scrum professionals, and addresses how it’s helped in certain cases, and how some of the scrum critics aren’t viewing it the way they should. Playfulness and seriousness complement each other, and when used correctly, is a great tool for improving your team’s relations, stress levels, and ultimately, productivity. I’ve changed my mind playfulness being unnecessary. A little levity is important for the mind and body, and I’ll definitely keep that in mind when I’m in a professional environment.

Link: https://medium.com/serious-scrum/a-serious-look-at-playful-formats-in-retrospectives-73aed21aa083

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

URL: https://getdx.com/blog/software-collaboration/

During this past semester, I learned more about what collaboration is and why it is so important. Collaboration is something that I personally find essential and key in software development. However, this semester, I learned the hard way how problematic the lack of collaboration from someone can be and how harmful it can be to a team. It doesn’t just divert attention from the focus, but it also disrupts the workflow and creates unnecessary stress. I don’t say this because I am the most collaborative person—believe me, I’m not. At times, I can be a difficult person to collaborate with. But through experience, I learned an important lesson: when team members don’t collaborate effectively, progress is slowed, creativity is hindered, and learning opportunities are missed.

You might ask me, “How would you bring together four or five different people from diverse origins, cultures, and sometimes even languages, and make them work seamlessly as a team?” Well, I don’t expect perfect communication or total synchronization—such perfection is simply unattainable. However, that doesn’t mean that everyone shouldn’t do their best to contribute. Does this mean the solution is cherry-picking people with similar backgrounds, races, and beliefs to simplify communication? The answer is still no. The strength of a team lies not in how similar its members are but in what they can contribute and their shared desire to grow and succeed.

Diversity within a team is also essential for solving complex problems. Individuals with different experiences and perspectives can offer unique insights and approaches that others might never consider. When people bring their varied backgrounds and creativity to the table, the possibilities for innovation and success increase significantly.

Ultimately, what matters most is the effort and willingness of each team member to collaborate and complete the work. Agile methodologies and Scrum are two approaches that I have found particularly effective in fostering a culture of communication and collaboration. Frequent check-ins, meetings, and milestone-based planning make it easier to stay aligned and on track as a team.

One blog post I came across this semester made me reflect on the importance of addressing issues directly. Ignoring problems, whether personal or within a team, doesn’t make them go away; it only exacerbates them. This realization pushed me to focus on self-improvement by being more open to new and different ideas. Even if an idea isn’t the most ideal solution, it can still lead to success.

Finally, open-source software is something I was unfamiliar with before. Now, I’m eager to contribute to such projects, especially those aimed at making a positive impact on the world.

From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.

The selection of an appropriate development methodology is important in every software project. The article “Top 4 Software Development Methodologies” by Mike McGuire provides a brief overview of the principles of Agile, Waterfall, RAD, and DevOps. Each methodology has unique strengths and challenges, making them suitable for different scenarios.

Summary of the Article

The article discusses four of the most commonly adopted methodologies in software development.

Agile Development Methodology: Agile emphasizes iterative development-release of functional software increments frequently for greater efficiency and customer satisfaction. While Agile is great in adapting to changing requirements, it requires high commitment and communication.

Waterfall Development Methodology: Waterfall is a traditional and linear approach that fits projects with clearly defined objectives and stable requirements. It’s easy to understand but can be slow and inflexible.

Rapid Application Development (RAD): This approach emphasizes rapid iterations with a minimum of overheads and hence is ideal for small to medium projects with well-defined objectives. RAD does, however, depend on experienced teams and well-defined user requirements.

DevOps Methodology: DevOps is rather a concept and culture than a methodology; it ensures collaboration across development, QA, and operations. It emphasizes automation and reliability, but challenges include adapting to continuous updates and regulatory constraints.

The article also introduces DevSecOps, which is a newer iteration of DevOps that integrates security in every step of development. This ensures that speed and safety go hand in hand in the production of software.

Reflection and Learning

Reading this article made it quite clear how much the development methodologies rely on the project’s aims and the team’s functioning style. For example, the very adaptability of Agile stresses its applicability in a strongly changing environment, while Waterfall’s structured approach is suited for projects with fixed requirements. This understanding helps me anticipate which methodology might be most effective in various situations.

What really caught my attention was DevSecOps, the integration of security into the development pipeline. This again highlighted the importance of embedding security practices early, as emphasized in some course works on secure software design. The move to collaboration and automation in DevOps and DevSecOps reflects changing demands in the software industry.

I have faced difficulties in projects where methodologies were not clearly defined, which resulted in wastes and miscommunication. This article shed light on how methodologies such as Agile and DevOps could minimize such occurrences. In the future, I will adopt the Agile practices in team projects to be more adaptive and productive. I also want to study DevSecOps in detail, as it aligns with my interest in developing secure and reliable software systems.

Application to Future Practice

Knowing such methodologies empowers me in informed decision-making while managing or taking part in software projects. I now know that while selecting Agile for its flexibility or Waterfall for clarity, I will understand how methodologies drive the outcomes of a project. The emphasis on security in DevSecOps inspires me to give top priority to secure coding practices in these present times when technology has gained center stage in our lives.

Citation

McGuire, M. (2024, March 24). Top 4 Software Development Methodologies. Link: https://example.com/top-4-software-development-methodologies

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

In software development, writing clean code is essential for creating maintainable, scalable, and efficient applications. The article “The Core Principles of Writing a Clean Code” by Arthur Coudouy provides valuable insights into the fundamental principles that contribute to clean coding practices.

The article emphasizes that clean code is easy to understand, simple to modify, and efficient to maintain. It highlights key principles for achieving clean code:

• Simplicity: Avoid convoluted logic; clear and simple code is easier to maintain and scale.
• Consistency: Use consistent naming and structuring to make code readable and predictable.
• Clarity Over Cleverness: Optimize for readability; complex solutions should not come at the cost of clarity.
• Code Review Automation: Utilize automated code review tools to enforce standards and maintain consistency across the codebase.

I selected this article because it aligns directly with our course material on best coding practices. Another reason I chose this topic is that being a programmer is not just about writing code. There are many important factors, such as debugging, making your code efficient, and ensuring it is easy for other programmers to understand. Understanding and applying clean code principles is crucial for developers to produce high-quality software and collaborate effectively within teams.

The article reinforced the importance of writing code that is not only functional but also easy to read and maintain. I learned that simplicity and consistency in code structure significantly enhance its scalability and efficiency. I also appreciated that the article provided examples of how the principles of clean code can be applied. The emphasis on clarity over cleverness resonated with me, as overly complex solutions can make understanding and make future modifications more challenging.

Armed with these insights, I plan to apply several strategies to improve my future coding practices. I will prioritize simplicity by writing straightforward code, avoiding unnecessary complexity to ensure maintainability. Maintaining consistency will also be a key focus; I will use clear naming conventions and structured code to make my work predictable and easier to understand. Additionally, I will emphasize clarity over cleverness, creating solutions that are easy to grasp and effectively communicate their purpose. Lastly, I intend to to use the automated code review tools to uphold coding standards and streamline the review process, fostering better collaboration and consistency within a team. By adopting these practices, I aim to contribute to the development of robust, efficient, and maintainable software for my future career as a software developer.

Sources:
The Core Principles of Writing a Clean Code

Citations:
Coudouy, Arthur. “The Core Principles of Writing a Clean Code.” Axolo Blog, Axolo, 31 Oct. 2024, axolo.co/blog/p/core-principles-of-writing-clean-code.  

From the blog CS@Worcester – CodedBear by donna abayon and used with permission of the author. All other rights reserved by the author.

In another podcast from Stack Overflow again by Ben Popper with special guest Johnathan Schneider, discusses the nature of technical debt surrounding open-source projects. The main example used throughout the podcast is refactoring code, switching from java 7 to java 8. And in later examples sometimes java 8 to like java 17. As they explain the difficulty when switching, especially when more manual work is needed, talk about the ways technical debt is created. After more discussion around the software he made to help refactoring, goes into more detail about the nature of technical debt. We think of technical debt as something that we impose on ourselves. Like taking shortcuts or code that needs to be updated. One of the main points of this podcast is to think about technical debt more as maintenance. Obviously sometimes it is self-inflicted, but often it just comes with the territory. As new things come out, things will need to be updated. It’s easier to think of it as something that needs to be done for the sake of the health of the program. Rather than as something I did that I need to fix because of my own short sightedness. 

I chose this podcast because it is related to our discussions of technical debt and refactoring code. In class, we talked about the nature of technical debt and how often it is a code structure thing or maybe a breaking change. It is more thought of as something that comes as a result of not thinking ahead. While I think that is true in many cases. I think a lot of the time it can’t be avoided, like in the case of code versions. Thus it’s better to think of it as maintenance rather than something that could have been avoided. For me, mentally saying that this problem is something that couldn’t have been avoided is better. If I think it’s my fault then I feel like an idiot and get down on myself. Maybe it is just a mental thing, but it goes a long way for the mentality of a person or team. Another aspect of the podcast I think it is important to think about is how the open-source nature plays a part in this. Code is being worked on at all times, different people. So when the code is updated and your code no longer works. It’s important to realize that this isn’t your fault and just is the nature of things. The code not working is not your fault and just needs to be maintained so it works again.

Citations

https://the-stack-overflow-podcast.simplecast.com/episodes/open-source-ecosystem-reduce-tech-debt/transcript

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.