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.

In this podcast episode from Stack Overflow by Ben Popper with special guest Ryan Donovan, discusses the evolution of documentation and the future of technical writing. The whole episode is about the nature of writing documentation is changing fast. With the advent of generative AI and other tools like linters that can automatically write or run tests make technical writing more automated now more than ever. One of the first talking points is why documentation is being pushed a lot more now. Increasingly because programmers don’t like writing documentation this job is delegated to technical writers. Who will go into code repositories and write documentation.These technical writers end up being some of the most important people when it comes to code structure. Since they write the documentation that defines how the program is specified and built. 

After moving through some background information the next talking point is the future of technical writing. This was of the most interesting parts to me because it discusses not only just the AI aspect, but things like how other tools play a role. The question then becomes will AI replace technical writers? The answer they concluded was no. Although it is able to generate and automate documentation. Often that documentation needs to be looked over. For the moment AI is not able to create fully functioning documentation to that level yet.

I chose this podcast because it directly relates to what we have been doing in class lately. Looking at the Open API yaml and documentation related files. I don’t think there is a specific lesson to be learned from this podcast. More about just thinking about the future of technical writing. As programmers, we will all have to interact with documentation at some point. Whether that be something like java docs or yaml files. I think it’s important to know what goes into making documentation and the people who write. Because it really is a career all in of itself. Like I mentioned before, one of the most interesting aspects of technical writing is how AI is changing the landscape. Like many areas right now, people are worried if their jobs are in danger. I think with a lot of other cases human supervision is still needed. Another point that I didn’t really think about before now is the importance of documentation other than just information. Like in the case of yaml files that define structure. Is how important it is because it literally specifies how software operates. Like the definitions of endpoints that must be fulfilled and other specifications.

Citations

https://the-stack-overflow-podcast.simplecast.com/episodes/your-docs-are-your-infrastructure/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.