This week, I will discuss the subject that was recently discussed in class. The topic is “Scrum”, understanding its purpose, application, and limitations compared to Agile. Understanding the specifics of Scrum can enhance teamwork within projects, particularly in software development, where it is a widely utilized project management approach.

The information I researched offered a detailed explanation of the factors that could lead to the failure of Scrum. An essential realization was that following Scrum rules without adapting them to a team’s specific needs could result in too much inflexibility. This really affected me because I have seen situations where teams got stuck in processes and forgot the main objective: delivering value to customers. It caused me to think about past projects in which team members prioritized adhering to protocols over achieving the end goal of creating a useful, practical product. The resource I examined offered a detailed explanation of the factors contributing to the possible downfall of Scrum. One crucial finding was that adhering strictly to Scrum guidelines without adapting them to suit a team’s specific needs could result in too much rigidity. This had a significant effect on me as I have seen situations where teams got stuck in processes, ignoring the main objective of delivering value to customers. It led me to think about past projects where team members prioritized following procedures over delivering a successful, useful end product.

I found out that Scrum offers a structured way of working, but its success depends on teams embracing Agile principles, not just following a set of tasks. The article pointed out that even the best-designed Scrum plans may fail if team members lack commitment or the necessary skills. This has emphasized the significance of establishing a solid team environment in which every member is valued and motivated to take part. The article also delved into how focusing too much on Scrum practices could result in unnecessary bureaucracy, hindering efficiency and restricting innovation.

I chose this blog because I plan to incorporate these lessons by promoting a culture of flexibility in my team. I intend to prioritize the Agile principles of collaboration, customer focus, and adaptability over strictly adhering to Scrum methodologies in our process. Regularly meeting with the team to evaluate our advancement and adaptability will be of utmost importance. Effective communication will allow us to adapt our strategies according to the project’s objectives and the team’s abilities.

Reflecting on the Scrum blog, I discovered its thoughts on the restrictions of the framework to be very informative. It highlighted how sticking strictly to Scrum may impede success, underscoring the need for flexibility. This mirrored my own experiences, as a lack of flexibility frequently resulted in difficulties. I discovered that emphasizing teamwork and transparent communication is essential for providing value. In the future, I intend to foster a flexible culture among my team, consistently communicating to ensure our practices are in line with our goals. This research has enhanced my comprehension of Agile methods and emphasized the importance of flexibility and dedication in project management.

Blog URL: https://medium.com/better-programming/why-scrum-fails-ac92cab05c6a

From the blog CS@Worcester – Matchaman10 by tam nguyen and used with permission of the author. All other rights reserved by the author.

This week, I am going to discuss some of the benefits of the output-oriented software development methodologies we have been studying in class, like Scrum and Agile. I have built many projects both on my own and for my career from the ground up, which is where the value of these methodologies is most apparent to me. The blog post I will be referencing throughout this discussion can be found here. This post provides an in-depth overview of the Agile methodology, including lower-level analysis of different stages of the process, benefits and purposes of each stage, and various best practices for different stages. I chose this post because it correctly emphasizes the importance the Agile methodology places on continuous delivery, which is something that has been a cornerstone for me in various projects.

A project that comes to mind is actually the same project I discussed in this week’s post for CS-343. A friend came to me and asked for something way above my skill level, and it was daunting to imagine planning out the whole project and implementing/deploying some large framework in any reasonable amount of time. If I hadn’t remembered something an old professional connection had said to me years prior, I don’t think I ever could have known where to start: “your code has to exist before it can be made better.” I think that is what the heart of these continuous delivery methodologies is really about, and it really is a true statement for many reasons. The first, which this blog touches on and which we have discussed briefly in class, is that your perspective will always be better or wider after the work is started. Another reason that statement holds true, and perhaps the most practical reason (at least in my case), is that half the time, I don’t even know what I am doing when I start. It would be impossible for me to design anything, because I don’t know anything. For me, learning my way through a project is almost all the fun, and that is not really an option without methodologies like Scrum and Agile, even if I don’t know I’m using them. This blog post discusses release management a lot, which is not so applicable to personal projects, but I think it connects nicely if you compare a release to a checkpoint or successful implementation of a new feature. In my project, as I built it, I started with: what. Then, I said, I guess I could try that. Then, I implemented a single shoddy feature. I saw my feature and saw a way to make it better. Compound that a hundred times, and I had a full framework that I had approached incrementally, following Agile principles and release management without even knowing it. I think that is a testament to the elegance of these continuous delivery oriented methodologies, and I will more consciously follow these principles moving forward.

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

In this post, I will be discussing some basic concepts about abstraction in object-oriented programming. The resource I reference can be found here. I chose this topic because in the first few group activities, I was made aware that I had forgotten some of the key differences between kinds of abstraction (at least in Java), such as the difference between an abstract class and an interface. Though we reviewed these differences in class, I wanted to continue to find specific examples that would allow me to better understand the concept. Abu’s blog post briefly explains what abstraction in object-oriented programming is, some of its benefits/purposes, and some elementary examples of how to implement (no pun intended) abstract classes and interfaces.

The largest point of note I want to discuss is the benefit of modularity when abstraction is implemented. I recently finished up a personal coding project, in which modular development was a necessity. The project involved a central framework capable of ingesting a very specific kind of data from different websites, but each of the websites had a different way of providing that data. The most efficient answer I could think of was to make the central framework independent of the websites themselves, and to make it deal only with the data after it was obtained. I then created a module for each website that held the data, and implemented whatever logic I needed to in order to get the data and pass it to the central framework. I used Python for this project, but in hindsight, I may have been better suited to implement an object-oriented programming language like Java. Each module could have been a concrete class that extends some abstract class Parser, as each of my parser modules in my Python project used the same methods anyways. Each module had a get_url_and_interactions() function, a get_parse_function() function, and an stm() function (we can leave that abstract for now). It would have been very simple to use an object-oriented programming language, as I could have abstracted what it means to be a parser.

Now, this worked fine; since I was the only developer on the project, and had full visibility over all of the code, I didn’t need to check if a module implemented, for example, the get_url_and_interactions() function. I knew that it did. Moving forward, if I were coding more collaboratively with anyone else, or even if I just wanted to code according to some better practices moving forward, I could have used abstraction to standardize the parsers to ensure they all implemented certain methods or functions.

Though a little cliche, I do think it is very nice and elegant that the same thing can be accomplished in so many different ways. I think it is a good metaphor for most problems worth solving.

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

The pattern I chose to write about from Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye is in chapter 3: Sustainable Motivations. I chose this as my first pattern to touch on because I find that motivation is something that I struggle with constantly. I already face days where I question my commitment. I did it today. Imposter syndrome got to me and I questioned whether I was cut out for this field. 

I agree with the argument that “it is crucial that your motivations to program are aligned with walking The Long Road”. Two of the examples of unsustainable motivations were money and thinking of programming as fun. Initially, my primary motivation for getting into this field was money; I did think it was somewhat fun to write code and think of solutions but I was thinking about a career path that would pay decently well. My line of thinking was impacted by how expensive it is to live and enjoy life. I figured that it’s best to just become a software developer because “It’s not like I hate it and it pays well”. After reading, I want to try figuring out what motivates me to stay in this field. I’m motivated by something that isn’t money or how fun it is because I’m still studying software development despite my struggles. 

I couldn’t find something in this pattern that I disagreed with but I don’t exactly understand the task from the action part. It instructed to “Write down at least 15 things that motivate you. Wait a little while, then write down another five. How many of your motivations are about what other people think rather than what you feel? Are the percentages different between your first 15 and the final 5? How many of the motivating factors can you do without? Now write down a list of the five most important things that motivate you”. I don’t understand the practice of writing down an initial 15 and then another 5 when you can keep the questions in mind as you write the last important 5. Maybe I’ll try it and figure it out.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.

Summary: 

The white belt pattern focuses on the idea that new situations should be approached with all previous knowledge set aside. The white belt signifies an entry level of knowledge and understanding of a subject, and is only achievable if all preconceptions and past experiences are removed during the learning process. This mental clean slate prevents old habits or patterns from getting in the way of exploring new possibilities when it comes to solving problems.

Reflection:

The more I reflect on this pattern the more I agree with it. However, my opinion felt like it went from agreeing to disagreeing back to agreeing. When in reality, it went from agreeing with some parts, and disagreeing with parts I didn’t fully understand. To eventually gaining an understanding of the pattern that I fully agree with.

Originally agreeing with the overall idea that you should have the mentality of a white belt when learning something new, I disagreed with the notion that all previous knowledge was bad. I, as do many others, learn by being able to take previous knowledge and experiences and relating them to the new situations. This however is the trap that this pattern is actually trying to avoid. The interesting part in this section that made me realize my mistake in my in initial interpretation was the “problem of ‘writing Fortran in any language.’” Not knowing what FORTRAN was, I researched it and found out that I was in fact making this same mistake. Learning a new language doesn’t mean just being able to recreate a simple program. It involves learning all the small nuances and limitations each language has. The only way to explore those is to approach each situation independently and with a clean slate.

My first language was java, and when it comes to learning a new language it is helpful for me to be able to relate things in the new language to elements in java. This turns out to be a trap if you are only looking for 1 to 1 relationships, or you let your old knowledge prevent you from learning something specific to the new language. The more I think back to all my older projects that involved learning in a language that was not java, all I actually learned was the syntax of how to rewrite my code in another language. My understanding of the language or coding in general did not get deeper. Having my previous knowledge acted more as blinders than guidelines, showing me the one way I already knew, but preventing me from seeing other possibilities I didn’t know even existed.

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

When working with a project that has already been built up to a certain point, one can find themselves lost in where to look first, how to accomplish their job within that project, how the program even works as a whole. I’ve had firsthand experience with this already working with the Thea’s Pantry system. Ultimately, the only way to really learn what is going on in the system is by looking at the code and trying to make sense of it.

This pattern is very important within the context of working in the Software Development field. The quote at the end is a synopsis of it: if a programmer can learn a codebase quickly after being hired, then they can more quickly be productive and add value to the project for the employer they are writing code for. Otherwise, you’re spending a lot of time just trying to get an understanding of things while you have deadlines coming soon.

The one thing is that obviously getting an understanding of a codebase is incredibly difficult depending on your level of knowledge in various languages and programming as a whole. Of course, this is one of the later patterns (chapter 5), but regardless if I don’t have much experience with JavaScript, trying to read a project that operates on JavaScript at a high level will be a bit more difficult than reading a project that uses C given that I have worked with C for a year, let’s say.

There’s also the consideration of documentation. Documentation can be very helpful, but there will always be cases where the code was changed and the documentation was forgotten about. This leads to additional confusion, and it only compounds when there are comments in the actual code that are misleading, or functions that weren’t written with clean code principles in mind. Everyone makes mistakes, and sometimes those mistakes lead to tech debt that has been compounded upon to the point where that bit of code that’s hard to understand cannot be changed without a whole refactor.

Of course, this is dependent on the project. I’m sure that projects like version control systems that were mentioned in the reading are fairly consistent because they need to be, and having the experience of learning a codebase like that is definitely useful and builds on adaptation skills that are somewhat of a necessity in the tech field. It’s an interesting thought, and I can see how it can lead to better code.

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

“Confront Your Ignorance” urges us to face our lack of knowledge head-on. Instead of shying away from what we don’t know, this pattern encourages us to acknowledge our ignorance and embrace it as a stepping stone to growth.

Key points of the pattern include:

1. Recognizing Blind Spots: We all have blind spots – areas where our knowledge is lacking or incomplete. The first step is acknowledging these blind spots and accepting that there’s always more to learn.
2. Seeking Learning Opportunities: Actively seek out opportunities to expand your knowledge and skills. Whether it’s through reading books, attending workshops, or collaborating with peers, every experience is a chance to confront your ignorance.
3. Embracing Humility: Embrace humility and be open to learning from others. Recognize that expertise comes from a continuous process of confronting and overcoming ignorance, rather than pretending to know it all.
4. Asking Questions: Don’t be afraid to ask questions, even if they seem basic or obvious. Asking questions is a sign of curiosity and a willingness to learn.

My Reaction:

“Confront Your Ignorance” resonated deeply with me, especially as someone navigating the complex landscape of software development. It’s easy to feel overwhelmed by the vastness of the field, but this pattern reminded me that it’s okay not to have all the answers.

One aspect of the pattern that particularly struck me is the emphasis on humility. In a culture that often values expertise and confidence above all else, it can be daunting to admit when we don’t know something. However, this pattern taught me that true growth comes from embracing our ignorance and using it as fuel for learning.

I’ve also realized the importance of seeking out learning opportunities proactively. Instead of waiting for knowledge to come to me, I now actively seek out books, courses, and conversations that challenge my existing understanding.

One point of contention I have with the pattern is the suggestion to ask questions, even if they seem basic. While I agree with the sentiment, I sometimes struggle with feeling like I’m bothering others with my questions. However, I’m working on overcoming this hesitation and embracing the value of curiosity.

In conclusion, “Confront Your Ignorance” has shifted my perspective on learning and growth. By embracing the unknown and confronting my ignorance, I’m committed to embarking on a journey of continuous improvement and discovery.

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

Summary: The “Find Mentors” pattern emphasizes the importance of seeking guidance and mentorship from experienced individuals in the field of software craftsmanship. It acknowledges the challenges faced by apprentices in navigating their professional journeys and advocates for actively seeking out mentors who can provide valuable insights and guidance. The pattern highlights the rarity of finding a master craftsman but encourages apprentices to engage with a series of mentors, recognizing that mentorship can come in various forms and may not always be face-to-face.

Reaction: This pattern resonates deeply with me as it underscores the significance of mentorship in personal and professional development. It acknowledges the inherent challenges in finding suitable mentors but emphasizes the transformative impact that mentorship can have on one’s journey towards mastery. I appreciate the practical advice offered in the pattern, such as lurking in online communities to identify potential mentors and taking the initiative to reach out to them for informal advice.

Interest: What I find particularly interesting and useful about this pattern is its emphasis on the reciprocal nature of mentorship. While apprentices seek guidance from experienced practitioners, they are also encouraged to pay it forward by mentoring others who are earlier in their journey. This aspect highlights the collaborative and communal nature of the software craftsmanship community, where knowledge sharing and mentorship play vital roles in fostering growth and development.

Reflection: The “Find Mentors” pattern has prompted me to reflect on my own approach to mentorship and how I can leverage it to enhance my professional growth. As I navigate my career in software development, I recognize the importance of seeking out mentors who can provide guidance, feedback, and support. Additionally, I am inspired to contribute to the community by offering mentorship to others who may benefit from my experiences and insights.

Disagreement: While I wholeheartedly agree with the principles outlined in the pattern, I believe that it could provide more nuanced guidance on navigating the complexities of mentorship relationships. For example, it could delve into strategies for building meaningful connections with mentors and managing expectations within the mentorship dynamic. Additionally, the pattern could explore potential challenges or pitfalls that apprentices may encounter in their quest to find suitable mentors.

Conclusion: In conclusion, the “Find Mentors” pattern serves as a valuable reminder of the importance of mentorship in the journey towards software craftsmanship. By actively seeking out mentors and engaging in reciprocal mentorship relationships, apprentices can accelerate their learning, navigate challenges more effectively, and contribute to the growth of the software craftsmanship community. As I continue on my own journey, I am committed to embracing mentorship as a cornerstone of my professional development and to paying it forward by supporting others along the way.

From the blog CS@Worcester – Site Title by rkaranja1002 and used with permission of the author. All other rights reserved by the author.

The Deep End pattern is about growing your skills and boosting your confidence. It’s also about challenging yourself with bigger things. Growth is significant, it’s about taking big risks and doing things you don’t usually reach out for. Taking risks may be scary but playing it safe doesn’t help you improve or leave you unsatisfied. The Deep End pattern means that people should take on big projects or high-profile roles even when they don’t feel ready to. The importance of finding mentors, building feedback loops, and seeking help when needed. People should want to take on challenges, even if there’s a chance of failure, can open up doors and opportunities that playing it safe never will.That pattern knows that there are risks involved but those risks can cause growth by being in a scary situation and getting passed your comfort zone.

I found the pattern useful because it’s supposed to not only build your skills but also build your confidence. Boosting your confidence is a skill that some people don’t think is necessary but it can open up so many opportunities. Just by being brave, taking risks, and learning from failures taking those experiences can help people shape a successful future. I would say that pattern has changed my way of working because usually, I want to take the safe side and not take any risks doing that would just keep me from fulfilling my full potential. Challenging my self will only better myself and the way I work. I don’t disagree with The Deep End pattern because it has the right idea of doing something risky so you can grow instead of being comfortable with where you are now. This pattern is about bettering yourself, learn from any failures you had in the past, and grow from them. Don’t let anything hold you back from shaping your future keep trying to succeed. This is a pattern I will use moving forward so it can not only help me become more successful by taking risks but also build my confidence so i’m not scared to take any opportunities ahead of me.

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