I was reading an article called “Why Scrum Fails” by Jason Godesky. The link is here: Why Scrum Fails | Better Programming. It is pretty a list of much all the pitfalls Scrum contains. The author lists many points for why Scrum is not a good wat to achieve Agility. He criticized the increments saying that they do not focus on customers and giving working software. He then criticizes self-managing teams by saying that managers can interfere. They could see their positions threatened, since there are no managers in scrum teams, and try to squeeze themselves into teams. Managers may try to take management task from the developer’s shoulders as a good gesture but in actuality they take away the team’s autonomy. No one is willing to just give up their role in the company. The author also mentions a “monkey’s paw” situation where companies that want to have a quick and painless way to improve output get it and later stunt the company growth. This is mainly because companies refuse to use Scrum to transform the company but instead delegate it to a developer only thing.

This made me think of what I learned previously about Scrum. I thought it was a structured and reasonable process. First there is the Sprint where ideas turn to value. Then Sprint Planning to plan for the work that will be done. Then the Daily Scrum which acts as a progress report. After that the Scrum Review which inspects outcomes and determines future adaptations. Finally, Review Retrospective which plans for the future. All of this seems reasonable. Although, after reading the article I can start to understand the criticisms. There is no role for the managers. But to counteract this I want to add that the managers could just become Scrum Masters. Maybe the role could be divided into two and have middle managers be involved. Also, there is no focus on working software but that could be added to the Definition of Done. Easy fix. To be honest it is strange to be introduced to something as a positive and helpful and then to immediate learn that it has so many faults.

To conclude, Scrum is not perfect which makes sense since it is man made. Also, a lot of the problems in Scrum is just how the companies enact it. For example, one critism was that Scum is mostly limited to developers and not companywide. Still there are still flaws. Nevertheless, I still think it is relevant to companies and would like to use it in the future. Overall, Scrum is not scum.

From the blog CS@Worcester – My Journey through Comp Sci by Joanna Presume and used with permission of the author. All other rights reserved by the author.

I was reading about the top four symptoms of bad code, and it reminded me of the classwork I did earlier today. At that time my group and I were learning about the Waterfall Methodology and the Agile Methodology.

But first, the article’s link is this: Top 4 Symptoms of Bad Code – Excella. To summarize, it lists rigidity, fragility, immobility and viscosity as symptoms of bad code. Rigidity makes code difficult to change and causes non rigid problems to stay unfixed. Fragility is when software breaks when it is changed. To simplify, it causes the common issue of when one bug is fixed and multiple spawn in its place. Immobility is when software can’t be reused which leads to code having to be duplicated. Viscosity is when the developer is hesitant to change their code. This can result in wasted time and energy.

Back to what I was saying earlier, this article made me think about how the symptoms of bad code would affect the development process under Waterfall Methodology and the Agile Methodology. Under the Waterfall Methodology, rigidity and fragility would delay the verification and maintenance process. Rigidity makes code hard to edit which would make the steps where a person would have to edit code especially difficult. Fragility would cause time to be wasted or worse, it could delay the whole project. Immobility would delay the implementation process since time that could have been spent somewhere else is being used to duplicate a piece of code. Viscosity has the potential to affect the deployment stage since it could allow a program with bugs to be sent to the customer. Think about how some video games tend to be published with bugs. If only one or a few developers suffer from viscosity, then it would only delay the verification and maintenance process.

Since the Agile Methodology is more fast paced any delay would be more significant. Rigidity, fragility, immobility and viscosity would all call delays or a rushed project that may not meet up to the customer’s expectation. Viscosity would allow problems to fall through the cracks. Immobility would waste precious time. Fragility would take away attention from coding and push it toward constant bug fixing. Rigidity would extend the time it takes to fix bugs.

Overall, I believe this article achieved two things: teaching me something and allowed me to make a connection to what I learned earlier. I liked that it was short, to the point, and easy to understand. I will use this information to recognize when I fall into this pitfalls and course correct in school and my future career.

From the blog CS@Worcester – My Journey through Comp Sci by Joanna Presume and used with permission of the author. All other rights reserved by the author.

Introduction:

In our final group assignment, we explored testing in Python, and just last week, I blogged about using Selenium. Sticking to this testing theme, it’s intriguing to compare Java and Python, two powerful languages widely used with Selenium for automated testing. Drawing on insights from a Testrig Technologies article, this post examines which language might be better suited for Selenium testing, offering perspectives that could influence our approach to future projects.

Summary:

The Testrig Technologies article delves into the strengths and weaknesses of using Java and Python with Selenium for automated web testing. It notes that both languages have robust frameworks and libraries to support Selenium but highlights Python for its simplicity and readability, making it generally easier for beginners to learn and implement. Java, on the other hand, is praised for its performance and extensive community support. The article provides a balanced view, suggesting that the choice depends largely on the specific needs of the project and the familiarity of the team with the language.

Reason for selection:

I chose this article because it ties directly into our recent assignments and discussions around testing in Python, and my personal exploration of Selenium. Understanding the comparative advantages of Java and Python in this context is highly relevant, not just academically but also for practical application in future software development roles.

When comparing testing with Selenium using Java and Python, several key similarities and differences emerge, each influencing how testers might choose one language over the other. Both Java and Python support Selenium with extensive libraries and frameworks that facilitate browser automation, which means testers can script complex user interactions on both web and mobile applications using either language. They also integrate well with testing frameworks and tools like TestNG and PyTest, respectively, allowing for comprehensive test suites and reporting features.

Personal reflection:

Reflecting on the article, I appreciated the straightforward comparison between Java and Python. Last week’s experience with Selenium and Python was quite enlightening, especially seeing how straightforward scripts can be with Python’s syntax. This article reinforced my understanding and opened up considerations on when Java might offer advantages, particularly in scenarios requiring robust performance or when integrating into larger, more complex systems.

Future practice:

With this knowledge, I feel better prepared to choose the appropriate language for future projects involving Selenium. Depending on the project’s complexity and the team’s expertise, I can make informed decisions on whether to lean towards Python for its ease of use or Java for its powerful capabilities and performance.

Conclusion:

Choosing between Java and Python for Selenium testing doesn’t have a one-size-fits-all answer. Both languages offer unique benefits that can be leveraged depending on the project requirements. As we continue to develop our skills in automated testing, understanding these nuances will be key to delivering high-quality, robust software

From the blog CS@Worcester – Josies Notes by josielrivas and used with permission of the author. All other rights reserved by the author.

Testing In context of software development is a critical process that involves systematically checking a program or system to ensure it performs as intended. In software development, It is really important to check our work making sure everything works as it should. When we write code using object-orientated programming (OOP) which is a common way to organize and write our software, we need a special kind of checking called Object-Orientated Testing (OOT). This blog dives into what OOT is, inspired by the detailed article from GeeksforGeeks , showing why it is different and important.
Summary of the resource

The article from GeeksforGeeks explains how testing for Object-Orientated programming is different than traditional testing. OOP deals with concepts like classes and objects (which are basically groups of functions and data that model real-world things). OOT then focuses on checking these classes and objects, along with how they interact with each other, which is not something you do in traditional testing. The article talks about the challenges of doing OOT, like making sure objects work well together and the need for different tools and strategies to do it right.

Reason for selection

I picked this article because it does a great job of showing how checking object-orientated code is different from the usual way of testing code. It fits well with what we are learning in class about how to build software, giving us a clear picture of how to make sure out OOP projects work well

Reflection:

Reading about OOT made me realize that checking our code in OOP needs more than just looking at each part by itself. We need to see how all parts work together. It was an eye-opener to learn about the different tools we can use for OOT and how it helps us find and fix problems early on.

Looking forward

This article made me more aware of how important it is to use OOT in my future projects. Knowing how to do this kinds of testing means I can make sure my software is solid and works well, which is very important for any software developer.

Conclusion

Object-Orientated Testing is a key skill for software developers, especially as we build more complex and interconnected software. The insights from the GeeksforGeeks article highlights the unique aspect of OOT and remind us why adapting our testing to match our coding style is crucial. As we tackle bigger projects keeping these OOT principles in mind will help us build better and more reliable software

From the blog CS@Worcester – Josies Notes by josielrivas and used with permission of the author. All other rights reserved by the author.

In the realm of user experience and product development, the concept of the
“Happy Path” is crucial. It refers to a streamlined, problem-free journey a user experiences when interacting with a product or service, aligning perfectly with their needs and expectations. This idea, vividly explained in a blog post by UserPilot (https://userpilot.com/blog/happy-path/), resonates deeply with the narrative of Disney’s classic, “The Lion King.” Here, I draw parallels between the Happy Path and the Pride Lands, contrasting it with the deviations that lead to the Elephants Graveyard, to underscore the importance of this concept in our course material.

The Pride Lands, in “The Lion King”, represents the ideal state or the happy path in user experience terms. This lush and vibrant ecosystem where everything works in harmony symbolizes a users journey where needs are met effortlessly, and satisfaction is guaranteed. The Pride Lands thrive under Mufasa’s reign, much like how a well-designed product or service flourishes when it aligns perfectly with user expectations and provides a seamless experience.

On the other hand, the Elephant Graveyard symbolizes deviation from the happy path. It is a place of chaos, danger and poor outcomes, the opposite of the Pride Lands. In our course, we learned that straying from the happy path in a product development or user experience can lead to complicated, unsatisfactory user interactions, Much like how Simba’s venture into the Elephant Graveyard leads to peril.

My interest in this particular blog post stems from its clear, engaging explanation of the Happy Path Concept. Making it highly relevant to our course material on product development. The analogy with “The Lion King” further sparked my curiosity, as it creatively demonstrates the importance of maintaining the Happy Path in real-world scenarios.

Reflecting on the content, I have learned that like in “The Lion King” where the well being of the Pride Lands depends on wise leadership and balance, the success of a product or services hinges on thoughtful design and understanding user needs. This has affected me by highlighting the importance of user-centered design and has made me more aware of the user journeys in the products I use daily.

In my future practices, I plan to apply these lessons by prioritizing user needs and striving to maintain the Happy Path in my designs. This approach will not only enhance user satisfaction but also contribute to the overall success of the products I will be involved with.

In conclusion, the Happy Path is a fundamental concept in user experience and product development. The comparison of the Happy Path with the Pride Lands provides a vivid illustration of its importance, straying from this path, akin to venturing into the Elephants Graveyard, can lead to unfavorable outcomes.

From the blog CS@Worcester – Josies Notes by josielrivas and used with permission of the author. All other rights reserved by the author.

As a student delving deeper into the world of computer science and software development, In class we recently came across the topic of software licensing. The article “Software Licenses” by Ben Lutkevich which can be found here offers a comprehensive overview of what software licenses are and why they are crucial in the software industry.

Summary of the article:

The article begins by defining a software license as a legal instrument governing the use or redistribution of software. It highlights different types of licenses, such as proprietary, free, and open-source licenses. Each with its unique set of rules and restrictions. The article shows the importance of understanding these licenses, especially for developers and business, to avoid legal pitfalls.

Why I choose this article:

I chose this resource well one because I have to make a blog post, but two because it was relevant to our coursework, and truthfully I was still slightly confused about it after our class discussions on it so I felt it would be appropriate to do further research. The article really highlighted the importance of licensing and the potential legal ramifications of non-compliance.

The content of the article was both informative and thought- provoking. It helped realize how software licensing is not just a legal formality but a critical component of software development and distribution. Understanding the different types of licenses, such as GPL, MIT, Apache and their implications can significantly impact how software is shared, modified, and commercialized.

In future practice, I anticipate to be more mindful of the licenses attached to the software I use and or develop. For instance, If I contribute to an open-source project, I now understand the importance of adhering to it terms. Similarly if I were to develop software I would be more aware of how to protect my intellectual property while respecting others.

The insights gained from this article extremely valuable for really anyone in the field of computer science. Especially those involved in software development. These lessons will for sure be a guide in my future decisions and actions

From the blog CS@Worcester – Josies Notes by josielrivas and used with permission of the author. All other rights reserved by the author.