Throughout the beginning half of my Fall 2024 semester, I’ve learned about development processes such as environments, strategies, and team policies. As the year has progressed I wanted to know more about the development process of software before beginning my blogs. After tackling AGILE and Scrum I have been interested in seeing other ways of team management, and potential connections back to AGILE. To begin in understanding these processes I first found an article designed around general team management. This article is found on desktime.com, and it is not focused particularly on computer science, but on managing a team. The article’s title is A guide to team management: Strategies and techniques to help you succeed by Viesturs Abelis

This post outlines key strategies for effective team management to boost productivity and morale. It first emphasizes the importance of creating a supportive team culture, where employees feel valued and heard, mentioning Google’s Project Aristotle which found that psychological safety and feeling heard are crucial for team success. The article states that managers should engage actively with their team, foster inclusivity, and lead confidently. It is stressed that managers must be considered part of the team. The article also mentions the need for a clear vision and direction, including both long-term goals like a mission statement and short-term objectives like Key Performance Indicators and Objectives and Key Results. It highlights that employees are more motivated when they connect personally to the organization’s values. The use of productivity software is also recommended to improve team management. Tools for time tracking, performance evaluation, and project tracking provide valuable data, helping managers optimize team performance and streamline workflow. The article continues to reaffirm that team management combines fostering a positive culture, setting a clear direction, and using the right tools to enhance productivity and success.

This was a good article to step into team and development-based blogs, as it is a very broad and applicable subject matter. This is a key step in constructing a blog based on understanding development environments and processes. Without having a baseline understanding of team management, tactics like AGILE can be confusing to grasp. I wish to refine my knowledge in this area and prepare for working in and managing teams going forward into classes like CS-448. Next in my blog I will look into articles relating to development environments, such as Docker or GitPod, or look into articles based around AGILE and Scrum principles.

Source:https://desktime.com/blog/team-management

From the blog CS@Worcester – WSU CS Blog: Ben Gelineau by Ben Gelineau and used with permission of the author. All other rights reserved by the author.

One of the topics we covered in Software Process Management this year is Scrum. I’ve always been curious about how big companies and tech corporations manage their teams and make everything work smoothly. In the article “Achieving Team Purpose and Pride with Scrum” by Sophia Ciocca, a Web Engineer at Spotify, she shares her team’s journey to creating a more efficient and structured routine using Scrum principles.

Sophia starts by describing the struggles her team faced when they first tried applying Scrum. Meetings felt unproductive, sprints were often left unfinished, and there was little connection between their daily tasks and long-term goals. To fix these issues, Sophia’s team reached out to a Spotify Agile Coach and decided to adopt the full Scrum framework, as outlined in the Scrum Guide.

This shift involved several key changes, like holding weekly backlog refinement sessions, simplifying sprint planning, improving sprint reviews, focusing retrospectives on actionable steps, and enhancing stand-ups. These adjustments helped the team stay aligned, better understand their workload, and communicate more effectively.

The results were impressive. The team’s efficiency improved significantly, and tasks were completed faster. They even tripled their monthly active users without adding more team members. Most importantly, the team gained confidence in their work and a stronger sense of pride and purpose.

I chose this article because it directly relates to the Agile methodologies and Scrum Guide we’ve discussed in class. I also wanted to understand how big companies use these frameworks to foster teamwork and efficiency. It’s fascinating to see how systems like Scrum can make a huge difference in how teams work together.

Sophia’s story highlights an important Agile principle: “responding to change over following a plan.” Her team’s ability to adapt their process while staying true to Scrum principles was key to their success. One of my main takeaways is that asking for help, like Sophia did by reaching out to an Agile Coach, can lead to growth and positive change.

As I prepare for my career in tech, learning how to implement Agile and Scrum effectively is crucial. This article showed me how small changes, like adding confidence checks to stand-ups, can improve teamwork and productivity. I’m excited to apply these insights in my future career and work with teams that value collaboration and continuous improvement.

Sources:

Achieving Team Purpose and Pride with Scrum

Citation:
Spotify Engineering, S. C. (2022, January 27). Achieving team purpose and pride with Scrum. https://engineering.atspotify.com/2021/05/achieving-team-purpose-and-pride-with-scrum/ 

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

This week, I will be talking about the differences between coding and hacking, some of the confusions associated with them, and what your skill set should look like if you are learning about being a hacker. One question that will receive lots of attention is, “Do I need to learn coding to become a hacker?”

Let’s jump right into this. First, it’s important to note that coding and hacking are closely tied, but have important distinctions. Coding is the act of writing machine instructions, or code for a computer, which can be done in many different languages. Hacking, on the other hand, is the act of identifying and exploiting weaknesses in a computer system or network, usually to gain unauthorized access to personal or organizational information (to put it simply, you are breaking in). Hacking is not always a malicious activity, and there are actually several examples where hacking is used for good, like with penetration testing. Unfortunately, the term has garnered mostly negative connotations for its association with cyber-crime. It is important to remember that hacking is a tool–where it is not the tool that matters, but rather the intention of its user (what they wish to do with the tool).

Without a doubt, coding is a prominent part of hacking that has helped shape what it looks like today. If you are trying to learn about hacking, or are interested in taking part yourself, you would likely be doing yourself a disservice by having little to no prior knowledge of coding, because of how intertwined they are–but it is not absolutely necessary. In fact, there are multiple forms of hacking that require little to no coding skill. For example, social engineering is a type of hacking that focuses on the social, human aspect of security rather than the technical aspects. These attacks rely on human nature rather than code, and aim to manipulate people into compromising their personal security, or even the security of an entire network or organization they may be a part of.

In the podcast, Chuck raises an interesting question about having basic, fundamental knowledge of coding (specifically mentioning functions and classes) and asks if it’s really necessary to go much further than that if you are trying to become a hacker. John responds, “You don’t need to go much further beyond that. When people ask [that] question, I always say no, but with a disclaimer that you should learn some programming, but you don’t need to learn absolutely everything… I am not by any means a software engineer or architect, but I can script; I can write a loop that might brute-force passwords… and you don’t need to know a lot of hardcore, complex programming concepts for that. You just need to know the basics for that.”

John makes some very good points as the show continues, and focuses on how a lot of the basic, rudimentary skills in programming are often the ones that require the most practice, because of their importance, and because of how frequently they are used to build more complex pieces of code. He believes that the best way to get that practice is by immersing yourself in the world of hacking and trying to solve those problems with the skills that you have.

In conclusion, coding and hacking, despite being so closely intertwined, have some very distinct differences, and as it turns out, you may not need to know as much as you think you do about coding in order to start learning about hacking or becoming a hacker yourself. Although you may not need to know everything there is about programming, having some rudimentary knowledge is really all that it takes for you to start and branch out from what you have.

This episode can be watched in full, for free here on YouTube: https://www.youtube.com/watch?v=T7AaBcNj-mA&t=0s

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

I chose the blog post, “People Don’t Understand OOP” by Sigma because it addresses recurring challenges in programming, specifically around OOP. Understanding how to improve my approach to OOP principles would help me write cleaner, more effective code that’s easier to maintain and adapt over time. Not following these concepts has led to messy code in previous years. Personally, I feel like I made a lot of these mistakes when I first started coding, however as more classes have gone by I have been able to break some of these bad habits. Unfortunately, there are times when I will make these mistakes when coding without thinking so that is what led me to choose this blog post, so I can learn how to not make these mistakes in the future.

The blog post  explores common misunderstandings surrounding Object-Oriented Programming (OOP). The author, Sigma,  argues that misconceptions often stem from oversimplified metaphors and an incomplete grasp of fundamental principles like encapsulation and abstraction. Frequent mistakes include equating OOP with buzzwords like inheritance and getters/setters, while neglecting its core concepts such as bundling related state and behavior into cohesive units (objects) and minimizing dependencies through proper encapsulation.

The post highlights that encapsulation is not merely about hiding internal state but about reducing interdependencies and ensuring modularity. Public properties, often critiqued for exposing internal states, are likened to getters and setters in their inability to prevent object coupling. The author points out that real-world OOP is much more nuanced, involving trade-offs that depend on the problem domain and language constraints. A detailed comparison of popular languages, including JavaScript, Python, Rust, and Go, demonstrates varying implementations of OOP features like inheritance, subtyping, and encapsulation. 

From the article, I was able to rethink my use of OOP principles and highlighted that simplicity and adaptability should be the goal when programming. Going forward, I plan to be more thoughtful about whether OOP concepts like inheritance are necessary or if simpler, more flexible design choices would work. The article taught me that well-designed OOP should evolve naturally rather than forcefully adhering to principles. This perspective will help me develop solutions that adapt to change more easily, making my work in software development more efficient and adaptable. After reading, I feel like I will be able to not make as many mistakes that lead to inefficient use of OOP creating a better and more efficient workflow when coding.

From the blog CS@Worcester – Giovanni Casiano – Software Development by Giovanni Casiano and used with permission of the author. All other rights reserved by the author.

This week, I found an article questioning the relevancy of UML as Agile development processes are becoming more and more used today. This was an interesting article for me to read as it points out some of the flaws with trying to use UML while developing software with Agile, but also a couple of potential ways it can still be useful. The overall notion I got from reading this article was that UML has it’s time and place, but it is certainly becoming a thing of the past as developers start to lean more toward an Agile development process.

The article states that in an Agile environment requirements are typically not defined in detail prior to starting the project, as well as the design of the software. As the project progresses, the requirements and design will usually evolve over time. Also, formal documentation during a project isn’t as much of a necessity while going through an Agile development process. These three big components of Agile clash quite a bit with trying to implement UML as UML pretty much requires the exact opposite of these three components. Basically, you can’t define the design and details prior to the project because of insufficient information which you would need with UML, and it would also need a lot of effort to update the UML diagrams as the project evolves.

There are a couple ways UML diagrams could still be useful as listed in the article as well:

Once development is completed, it may be helpful to use UML diagrams to support the system. Using UML to define and standardize the architecture would also be another reason to still practice it.

I think, as I stated earlier, there is a time and a place for using UML. Obviously, if you haven’t adopted an Agile development process then UML could still be on the table to use; most people do use Agile now though. Because of this, you can certainly still use UML diagrams, but if you want it to be in an efficient manner, it should be used in one of or both of the ways mentioned directly above. It’s still great to have the knowledge of most certainly, as UML from what I’ve read and heard other people speaking isn’t completely outdated, but it definitely isn’t going to be something worth stressing over if you’re not the most knowledgeable on how it works.

From the blog CS@Worcester – RBradleyBlog by Ryan Bradley and used with permission of the author. All other rights reserved by the author.