With the constant updates that software can endure, there have been schemes that help track each update. Software versioning is the process of assigning either unique version names or numbers to unique states of computer software. This allows programmers to know when changes have been made and track them. There are several different types of versioning schemes, including name versioning, basic versioning, and internal and external versioning.

Name based versioning identifies software with words and labels rather than a numerical value. This is usually less structured than some of the numerical versioning systems. A basic versioning scheme uses simple, numeric values to track changes. While it is simple and easy to understand, it may not provide detailed information about the nature of the changes with previous versions. Internal versioning, also known as internal build numbers, is used within an organization or for internal purposes to track and manage different iterations. This is separate from external versioning, which is used to communicate with users. The versioning scheme we have started to learn about in class has been semantic versioning. This is a format that I have seen before, but personally did not know much about how exactly the scheme works.

Semantic versioning, also referred to as SemVer, is a versioning system that has the ability to provide a universal way of versioning software development. It is represented by a 3-component number (X.Y.Z) to represent the three different software releases. The Z value indicates the releases for bug fixes, with no functionality changes coming in these updates. Y shows a minor version update where a new functionality is introduced. When increasing the Y value after an update, you must reset the Z value back to 0. The X value denotes a major version, which breaks the current API. It is helpful to split up the different updates that the software endures in this manner so that the user knows the importance of each change.

There are advantages that SemVer brings to software development. It is a fairly simple scheme which provides the ability to track every transaction and help manage dependencies. This also helps the user to identify the risk of taking on the updated packages. It is a very valuable option for version management, especially when it relates to open-source and collaborative development environments.

Semantic versioning and impact of breaking changes in the Maven repository – ScienceDirect

From the blog CS@Worcester – Jason Lee Computer Science Blog by jlee3811 and used with permission of the author. All other rights reserved by the author.

In this week’s blog post, I will be discussing some of what I learned about the DRY design principle from the article “The DRY Principle: Benefits and Costs with Examples” written by The Valuable Dev. I initially chose this particular article because it perfectly aligns with the DRY design principle topic within the syllabus. This article discusses what DRY is, as well as why you shouldn’t always use DRY. I personally found the author’s use of humor to be very refreshing. I feel many of the blogs I have read so far have seemed to be robotic in how they are written.

The article says that DRY is primarily about a repetition of knowledge first and foremost. “Therefore, the logic of this shipment should only appear once in the application. Why? Imagine that you need to send shipments to a warehouse. You need to trigger this behavior in 76 different places in your application. No problem: you repeat the logic 76 times. After a while, your boss comes to you and asks you to change this behavior. Instead of sending shipments to one warehouse, you need to send them to three different ones. The result? You’ll spend a lot of time on your shipment logic since you’ll have to change it in 76 different places! This is a waste of time and a good way to produce bugs to piss your boss off.” The author suggests instead of repeating the logic that you are using, and it would be better to use abstraction to prevent the kind of issues that the example given causes. This would not only allow for changes to be made faster but also minimize the risk of bugs being created because you are only changing code in one area instead of 76 different places.

The author also discusses a situation where DRY doesn’t apply. In this example, the author is working on software for a VOD (video on demand) platform that both filmmakers and content teams would use regularly. The author was considering creating abstract classes to use instead of the current implementation that was being used due to many classes being almost copy-pasted, as well as seemingly having similar utility for both filmmakers and content teams. “In many cases, we knew that the interface would evolve differently in the future. We would have created a lot of conditionals in the controllers’ actions if we had created one set of controllers for both applications. Nobody wants a forest of if statements; the resulting code would have been way more complex. Additionally, the controllers shouldn’t contain any business logic. If you recall the definition of the DRY principle, it’s this knowledge and business logic that should not be duplicated.” As both classes would become more developed in the future, they would differ significantly. If they were made into an abstraction, the code needed for them to work for filmmakers and content creators would have been messy and complicated to manage.

Article: https://thevaluable.dev/dry-principle-cost-benefit-example/

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

This week in class, we went over the process of Scrum. Essentially, it is a loose framework on how a team should be working if they want the greatest potential from that work. I say ‘loose’ because it is loose, other than providing how the process should go, it allows teams to not only follow this framework, but adapt it and make it unique for their team and their work. I like this methodology for this reason. 

Scrum states that a team consists of developers, a product owner and a scrum master. Each has their own roles and responsibilities in the process. The process has five parts. The main event is the Sprint, which is a one month process where everyone is working in order to achieve a goal. Before this can happen, there is the Sprint planning, which is planning the Sprint and figuring out what needs to be done. Everyday before people start working, there is the Daily Scrum, a short meeting about what needs to be done that day. At the end of the Sprint, there is the Sprint review, going over the results and progress of the Sprint, and the Sprint retrospective, reflecting on the Sprint, as a whole and on individual parts, so that the next Sprint is better. Each part, and the roles, are described in detail in the Scrum guide.

In this blog post, Gregory Crown and Robert Pieper talk about how Scrum could be used outside the realm of software development, like marketing. I chose this particular post because not only does it connect to what we’re learning in class, it talks about how Scrum can be used outside of software development. In the post, they specifically talk about how marketing can use the framework of Scrum, and how it benefits from it. Pieper says that if it is a complex activity or problem, Scrum can help. He describes complex as something requiring a lot of opinions. He uses a water bottle as an example, saying one stakeholder may not like the color, another may ask what the purpose of the rubber thing at the bottom of it is, etc. Essentially, if you show the benefits of something, and there are a lot of different opinions on it, you can benefit from Scrum. He describes it in a very nice way, saying, “if you’re in a subjective environment where you’re getting a lot of opinions, use Scrum.” He says that if what you’re working on is something that just meets requirements, and then moves on, you don’t need Scrum. 

Personally, I agree with what he says. On paper, Scrum is an excellent framework for a lot of things. It has the layout on how to do things, but allows people to fill in the rest, however necessary for things to be done. It is a clean way of doing things, strict yet flexible. This shouldn’t just be a computer science thing either, if others can benefit from this, do it.

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

This week, I wanted to further research software design principles and guidelines. In my past coding projects, there wasn’t any set framework or model I would stick to when writing my code. This led to creating classes that depended on each other too closely, and methods that attempted to accomplish too many tasks at once. To create better functioning software, I’m going to need to learn the best design practices to abide by at the outset of the project.

A popular set of design principles among software professionals are the SOLID design principles. Named by Robert C. Martin, SOLID is an acronym for 5 design principles that lend themselves to efficient, functional software. These 5 principles are:

1. Single Responsibility Principle
2. Open / Closed Principle
3. Liskov Substitution Principle
4. Interface Segregation Principle
5. Dependency Inversion

This blog post from the Stackify website focuses on the Single Responsibility Principle and its role in the software development process. Robert C. Martin describes the Single Responsibility Principle as “A class should have one, and only one, reason to change.” Abiding by this principle may help avoid unintended consequences from future updates to the software, as fewer interactions may break as a result of changes to the code.

Even small-scale software projects will likely change significantly over time, and keeping the Single Responsibility Principle in mind will prevent your classes from being encumbered by unnecessary dependencies on each other. If a single class is called upon by many other classes within your software, changes to that class may break the functionality of any classes dependent on that parent class.

Making an effort to keep components of your program independent of one another also has the benefit of keeping your project simple for a human to understand and explain. When a piece of software can be understood by the developer or team of developers working on it, the flow of productivity is so much greater since fewer effort is being spent on deciphering how the software functions. Updates and new features can also be released more quickly and consistently when the structure of the program is easier to modify without compromising the interactions between its components.

Abiding by the Single Responsibility Principle does not mean only creating classes with a singular function, however. This approach can lead to the same problem of too many classes becoming dependent on a singular parent class, and unnecessarily complicates the structure of your program.

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

Overview

The objective of any scrum project management framework is to provide structure, fluidity, values and principles when completing a project. But all members of the project must equally pull their weight as well as know their role for the use of scrum to be efficient. A famous saying that relates to this is that “a team is only as good as its weakest link”. This phrase can be applied to basically any team, or group of people pulling for the same cause, in life. I think a scrum team is no different. This article I read by Dave West goes in detail about each role in a scrum team and how they tie in to each other for the team to collectively succeed.

Scrum Team Roles

Previously stated in class, the three roles of a scrum team are: the development team, the product owner, and the scrum master, with each role being just as important as the other. Starting with the development team, the developers are the ones responsible for working on the product. They are the ones bringing the blueprints and requirements, brought from the product owner, to fruition, essentially doing the dirty work of the team. The product owners show them what needs to be done and the deadline by which it needs to be done, and the developers take it from there. They self-organize and make their own decisions on how to complete the task. The development team could be of any occupation from writing, designing, programming, etc. The prime responsibility of a product owner is understanding business requirements and customer feedback. Based on those two things, the product owner is able to set the focus of the team based on meeting deadlines and release dates. It can sometimes be stressful and overwhelming for developers and product owners having to avoid falling behind. This is where scrum masters come in. The scrum master is the overseer, the piece holding everything together. The scrum master must have knowledge in development and product ownership. The development team and the product owner must be able to count on the scrum master for help and support. The scrum master is responsible for the scrum working as one and keeping the values strong in the team, sort of like a coach. The scrum master is usually the most active member of the scrum team.

Conclusion

As previously stated, I think for scrum to work, all members should be on the right pace. The minute that one role falls behind is the minute the framework fails. With much communication, and all members collectively on the right track, scrum is a very strong framework.

Article I Used

https://www.atlassian.com/agile/scrum/roles

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

article link at the end

Overview

This week we began learning about different types of software methodologies, mainly focusing on SCRUM. Scrum, being one of the most popular software development organizational processes, has many factors to consider and to improve on. One of these pieces is the Scrum Meeting, a 15 minute or so meeting with your co-workers and “boss(es)” discussing the day’s work. However, such meetings can easily devolve or change into different forms; certain groups function differently. For example, one team of developers may find it beneficial to have shorter 5-10 minute meetings where there is less communication from each member. Another team may prefer longer meetings with each developer participating in a detailed discussion. But what should it really be about? How should people really be involved? This is where Mike Cohn’s article Daily Scrums: Synchronization Meetings, Not Status Meetings comes in.

What Not To Do

Cohn, a specialist in agile processes and helping companies utilize teams effectively, believes that many companies do Scrum meetings incorrectly. Most current scrum meetings involve each developer giving a report to their scrum master, whilst the other developers sit and wait their turn. Instead, he states that “the daily scrum meeting is designed for team members to synchronize their effort” (Cohn). This opposes the idea of such meetings being used to simply share what one is working on, and move on for the day.

Cohn’s Beliefs

Cohn believes that daily scrum meetings should have members enthusiastic about the project they’re working on with their team along with the progress being made. Such developers should also be sharing their progress and thoughts not only with the scrum master, but with the rest of the team as well. This encourages a broader discussion with more voices and teamwork involved. 

Cohn encourages Scrum Masters to participate in daily meetings, as they can then hear about impediments while also showing support for their team. Lastly, Scrum meetings should have brief updates that focus on what has been accomplished rather than what one spent time on.

Thoughts

I chose this article because it gives a truer, more refined approach to Scrum compared to the ones mentioned. Since I am a beginner to the idea and process of Scrum, I did not know of some of the problems with current iterations of daily scrum meetings. 

This article has been very helpful to me as it introduces what daily scrum meetings should be like. In the past, I had a misunderstanding about how Scrum meetings went; which lined up with what Cohn advised not to do. Although I have not had any real-life experience with Scrum meetings, I feel better prepared as for what to expect in future jobs. I will most likely be using this newfound knowledge in future projects, whether internship or job, big or small. I understand now that it’s best to look forward to scrum meetings as a time to come together and share, and to leave with excitement about progress.

Article: Daily Scrums: Synchronization Meetings, Not Status Meetings

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

Summary: Semantic Versioning (SemVer) is an essential system for versioning software. This blog post explores its core components, including major, minor, and patch versions. It also delves into pre-release and build parts and how version precedence works in SemVer. At the heart of SemVer lies a structured approach to versioning. It all starts with three fundamental numbers: major, minor, and patch. Each of these numbers carries specific meanings, making them the building blocks of compatibility and change management.

Reason for Selection: I chose this resource because semantic versioning is crucial in software development, and I wanted to gain a deeper understanding of how it works. This is also in line with what we are covering in class and in the development of Thea’s Food Pantry.

Comments on Content: The resource does an excellent job of simplifying the concept of Semantic Versioning. It provides a clear explanation of how version numbers are structured and the significance of each part. I now understand that the MAJOR version indicates major, potentially breaking changes, while MINOR versions introduce new features in a backward-compatible way. PATCH versions are for bug fixes.

One aspect of SemVer that I found particularly enlightening was the discussion on pre-release and build parts. Pre-release versions, marked with a hyphen, are often used to share software informally for testing. They may not be stable and might not satisfy compatibility requirements implied by the normal version. Build metadata, indicated by a plus sign, is used to record information about the build process, like who made the build, build machine, and more. This is especially valuable for tracking software development. I could

Understanding the precedence of version numbers is crucial for managing dependencies effectively. The resource explains that version comparison in SemVer is done from left to right. Versions that only differ in the build part are considered equal. Pre-release versions have lower precedence than their standard counterparts. Numeric identifiers always have lower precedence than non-numeric identifiers. This knowledge has provided me with a better grasp of how to choose the right versions when managing project dependencies.

Personal Reflection: This resource has clarified many of my questions about Semantic Versioning. It has demystified what can be a complex topic, making it accessible for developers at a beginner or intermediate level of experience like my own. Now, when I encounter version numbers, I can make informed decisions about their compatibility and the potential impact on my projects. As a software developer, I anticipate that this knowledge will be invaluable in ensuring the smooth integration of various software components and libraries. It will help me avoid compatibility issues and streamline the process of managing dependencies, ultimately saving time and effort in the development process.

Link: Semantic Versioning Resource

From the blog CS@Worcester – Abe's Programming Blog by Abraham Passmore and used with permission of the author. All other rights reserved by the author.

A little journey on the others blogs to learn more about Agile methodology

The Evolution of Agile Practices

Is Agile Going Mainstream?
Agile methodologies have been a driving force in the world of project management and software development for years. They have reshaped the way teams approach projects, placing a premium on adaptability, collaboration, and flexibility over traditional, rigid methods. However, recent trends and discussions in the Agile community have sparked curiosity about the future of the Agile movement. Is it transitioning, shrinking, or possibly assimilating into conventional project management practices? This blog post delves into these intriguing discussions.

The Impact of Remote Work

One reasonable explanation for the drop in in-person conference attendance is the surge in remote work. The COVID-19 pandemic illustrated that remote collaboration is not only feasible but also effective. The convenience of virtual events may play a significant role in the decreased interest in physical conferences. As individuals discover that they can access valuable insights and networking opportunities from the comfort of their homes or offices, the shift away from in-person events becomes more comprehensible.

The Necessity of Agile Evolution

In a recent article, Stefan Wolpers explored whether Scrum, one of the most widely used Agile frameworks, needs to evolve. He discussed potential interfaces and changes that could enhance Scrum’s adoption and boost business agility. These conversations emphasize the ongoing need for Agile to adapt and evolve in response to the evolving demands of the business world.

Conclusion

Agile has undeniably left an indelible mark on project management and software development. Its emphasis on adaptability, collaboration, and flexibility has transformed the way teams approach projects. While conference attendance may be dwindling, the demand for Agile skills and practices is on the ascent, indicating that Agile is becoming absorbed into mainstream project management.

However, the evolution of Agile is far from over. Discussions about adapting Scrum and the need for hybrid approaches indicate that the Agile movement is still actively evolving to meet the demands of a changing business landscape. As we move forward, the key is to strike a balance between traditional project management and Agile practices to ensure successful project outcomes. Agile has not disappeared; it’s simply maturing and growing in influence.

This blog post delves into the evolving landscape of Agile methodologies in project management and software development. It examines the decline in conference attendance, which could signify the integration of Agile practices into everyday work. The post also highlights the impact of remote work on in-person events, the growing fusion of Agile into traditional project management, and the imperative for Agile to adapt to changing business needs.
Here is the link of the blog that I read https://www.leadinganswers.com/

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

In the ever-evolving world of software development, there’s a principle that often serves as a guiding light, a beacon of practicality amidst the allure of endless possibilities. It’s called YAGNI, which stands for “You Ain’t Gonna Need It.” This principle challenges developers to adopt a minimalist approach, focusing on what’s essential and avoiding the temptation to add functionality that may never be used.

At its core, YAGNI encourages developers to resist the urge to build features, components, or solutions that are not immediately necessary. It advocates for a “just-in-time” mindset, where development efforts are directed only towards addressing the existing requirements. The rationale is straightforward: speculative or preemptive additions can lead to unnecessary complexity, increased development time, and even bugs. By embracing YAGNI, developers maintain a clear focus on the immediate goals, prevent “over-engineering,” and ensure that the software remains lean and efficient. The principle not only enhances software development but also simplifies the debugging process and ensures that the codebase remains clean and manageable.

While YAGNI is a powerful concept, it’s essential to strike a balance. The key is to avoid unnecessary features but still be open to evolving requirements. Flexibility is vital, and YAGNI shouldn’t be used as an excuse to resist necessary changes. In the dynamic world of software development, simplicity, adaptability, and efficiency remain the true hallmarks of excellence.

References:

• YAGNI: You Aren’t Gonna Need It
• The YAGNI Principle
• Principles of Agile Development: YAGNI

From the blog CS-343 – Hieu Tran Blog by Trung Hiếu and used with permission of the author. All other rights reserved by the author.