Category Archives: CS-348

Scrum: Is it really that bad?

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.

Performance Testing – should never be overlooked

URL: https://blog.scottlogic.com/2024/09/17/performance-testing-the-often-overlooked-ingredient-in-web-application-success.html

Performance testing—the often overlooked ingredient in the success of web applications—was written by Andrew Whitmell. In his post, Andrew explores a certain type of software testing method that he claims is sometimes overlooked. He also discusses various topics to show that performance testing is vital. One of his main points is that, over the years, users and companies have been seeking more and more performance. As Andrew demonstrates with various external data, better software performance leads to better business performance. The different topics presented by Andrew relate to the various benefits that performance testing brings.

I always try to break down my process of selecting something to read or listen to into steps. I do not like to base my decision solely on an article’s title, as it can be misleading. However, I tend to read the article’s title, open it, and also read the subheading. First, Andrew’s title caught my attention because he considers performance testing something that is often overlooked. In my opinion, performance testing should be a priority among testing methods. I chose to write about this post because it presents a different point of view from mine. An application, or the idea of an app, always arises from a need to resolve some kind of issue. Taking this into consideration, we can say that performance should always be a goal of any application.

I would like to highlight a couple of topics covered by Andrew, namely the identification of bottlenecks, the optimization of resource utilization, and SEO boosting. I had not heard of bottleneck identification as a method for improving application performance. Interestingly enough, I was talking to a friend of mine a few days ago about software runtime complexities. We discussed a well-known programming problem called Two-Sum, and he mentioned that utilizing hash maps for this problem improves the runtime complexity from O(n²) to O(n). Just as Andrew points out, the identification of existing bottlenecks in an application can enhance its performance.

The optimization of resource utilization involves testing the program under extreme conditions that are not expected to occur daily. The results from such testing will allow us to identify whether we can better utilize what we have or if we are overspending on certain services. I would also like to mention that SEO boosting is vital for large companies, but not as much for small or local ones. I have seen many local or small companies that do not necessarily provide a web application but have a website for their product. Most of those companies overlook SEO boosting. The amount of time users spend on a certain page depends on its performance, and SEO rankings are highly affected by performance.

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 downfall of “Scrum”

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.

LeadingAgile SoundNotes: an Agile Podcast

Blog Title: Aligning Product-Driven Organizations with Customer Experience: Key Insights

This week, I listened to a podcast titled “How to Align Your Product-Driven Organization to the Customer Experience.”  The episode goes into and explores the challenges that product-driven companies face in ensuring their offerings truly meet customer needs. It explains in detail how organizations can align internal processes and product development strategies in concert with the overall customer experience and emphasizes the importance of both understanding and responding to customer feedback throughout the product life cycle.

The host starts off by discussing the gap that often exists between a company’s internal product focus and what customers actually want. They explain how organizations can get caught up in their own innovations, losing sight of customer pain points. The podcast stresses the need for continuous customer engagement, using both qualitative feedback and quantitative data to drive product decisions. They also highlight the role of cross-functional collaboration, urging teams across departments to work together to create products that not only function well but also deliver real value to users.

I chose this podcast because it directly relates to our course discussions on systems thinking and customer-centric design, both of which are crucial in software development. This points to a greater and broad development process: aligning internal systems with customer’s needs externally. More particularly, I felt that the guest speaker has done a very good job in bridging the gap between product innovations and customer satisfaction, a very crucial gap in most of the tech-driven industries today, including software development.

The one important thing I took from the episode has to do with how significant it is to assess products from a customer’s perspective. This is something that up until this point I had considered in terms of features against functionality. In this podcast, it helped me understand how important it would be to always reassess if those features actually impact the user experience. I also liked the talk about cross functional teams because it helped me confirm that successful collaboration among different departments brings much better results for any product. 

With my understanding now, using what I’ve learned can be used to integrate  into my approach to project work. Whether it’s in software development or product management, understanding the customer’s journey will be key to delivering value. I now see the importance of continuous feedback loops and how integrating customer experience into every phase of development can lead to better, more successful products. This episode has given me a fresh perspective on how to bridge the gap between product design and customer satisfaction, and I’m excited to apply what I’ve learned in future team projects.

Link to Podcast: How to Align Your Product-Driven Organization to the Customer Experience

From the blog CS@Worcester – Harley Philippe's Tech Journal by Harley Philippe and used with permission of the author. All other rights reserved by the author.

WEEK 1 | Employing Agile Methodology In Scrum Master Role.

Article URL: https://clickup.com/blog/scrum-master/

The article chosen, written by the PMO Team, group responsible for moving the needle across various projects at ClickUp, discusses the vital job of a Scrum Master lies in promoting teamwork, eliminating roadblocks, and making sure execution of Agile principles to achieve successful project management !! The article is called “How to Become a Scrum Master: Skills, Tools, and Tips”; in essence, examines the duties and significance of a Scrum Master. The Scrum Master promotes dialogue among stakeholders, the product owner, and the development team while emphasizing the aim of constant enhancement. I personally was interested in this article as it applies to the agile methodology. Agile has been a topic of discussion in our lectures in the past couple of weeks and has been greatly employed in our POGIL activities. To add on to the Scrum Master lesson we had this past week, it was pivotal to come to an understanding of how all this applies together.

I chose this resource because it offers a thorough and understandable summary of the Scrum Master’s responsibilities, which is in line with my studies on Agile techniques and project management in CS-348. I found the article to be very helpful in helping me better grasp Scrum and other Agile methods because it breaks out details of the role in a straightforward way. 

I could relate to the blog post’s topic on a number of levels. I had some misconceptions regarding the function of the Scrum Master, which it cleared up first. I had kind of thought of the Scrum Master as the team’s “administrative” position before reading this. But the article made clear how much more dynamic this position is, needing the person to be a servant + leader who continually strikes a balance between the team’s requirements and productivity while preserving Agile principles. The focus on the Scrum Master as a facilitator rather than ‘traditional’ manager was what really caught my attention. The differentiation matters because it shows how the Scrum Master, instead of assigning tasks, enables the team to self-organize. With this discovery, my perspective on leadership in Agile settings has completely changed. I now see that good leadership is about empowering people to perform at their highest level, not about having control over them.

This resource has taught me that becoming a Scrum Master is more than just knowing the fundamentals of Scrum. It also involves combining soft skills like empathy and communication. This understanding will change the way I handle Agile project management from now on. For example, I now see how crucial it is to maintain a collaborative atmosphere where team members feel motivated and ready to take responsibility for their work. In order to create a positive team environment, I will continue to work on cultivating my assistance techniques and look for roadblocks that might prevent development.

From the blog CS@Worcester – Just A Girl in STEM by Joy Kimani and used with permission of the author. All other rights reserved by the author.

On the subject of Output-Oriented Software Design…

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.

High Quality Software Development

Podcast URL: https://www.youtube.com/watch?v=alUfh7Nk4eE

The podcast I chose is presented by Patrick Akil, and this specific episode features Eugene Fidelin. Eugene, as described on his LinkedIn profile, is an Engineering Manager and Frontend SME at eBay Advertising. The two participants discuss many subjects related to high-quality software development, including topics like bug prevention, testing, the balance between speed and quality, team performance, and many other subjects. One piece of advice, in case you would like to listen to the podcast, is that its timeline on YouTube is broken down into various topics, making it easy to find a specific subject

Many times, I start reading an article or listening to a podcast, and it does not hold my attention. However, this podcast kept my attention throughout its entire length for two reasons: the way it is produced and the way the topics transition from one to another. It is not very technical, which makes it easy to understand, and it dispenses the need for visual aspects deliver all the information. It feels very much like a conversation between two people who enjoy what they do.

While listening to the podcast, I took notes on a couple of topics and phrases that caught my attention. Right in the first few minutes of the podcast, Patrick and Eugene discuss resilience and predictability. They make a great point, stating that every program’s goal should be to be both resilient and predictable. However, creating software that is completely resilient can make it difficult to modify, meaning that adding or changing something could break a certain part of it.

The last three topics that caught my attention are all about testing. I believe they interested me most because I have not delved deeply into any kind of testing. The first topic is about good practices for testing programs, which includes testing the frontend and the API separately, and then running tests on both together. Another interesting topic related to testing is observability over prevention in edge case tests, meaning that sometimes observing behavior over time might be more beneficial than running tests on edge cases, especially since continuous testing of such cases may slow down the testing process. Another great comment was about which type of test to use for either frontend or backend; not every type of test will fit every backend, and not every type of test will fit your frontend design.

I plan to use this advice and these practices in my career to achieve better results. I would also like to highlight another topic mentioned at the end of the podcast: not every person fits every team. It takes more than just a resume to determine if someone fits the team’s style.

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.

What is Technical Debt

The Future you Problem

Photo by cottonbro studio on Pexels.com

Hello and welcome to a new week on this beautiful blog of mine. Today is a topic that is of interest to me and possibly everyone reading this. It could also be something you ran into during a coding project. It is called Technical debt, which is the concept of delaying or omitting work to complete a project but cause more work to do in the end. 

Let me give you an example that I have dealt with, and that you may have also dealt with. So you got a coding assignment to do right and that deadline is coming fast. So you set out to do it in the quickest and easiest way possible without a care for code layout or etiquette, it is just you working on it after all. The next day, you think to yourself that you may need to rework some facets of the code to make it run better or make it look neater. You then open up the project and look in horror at the mess you made and realize that it would take more time and effort to make it neater or run better than it would be to just continue on and get the project done. That is technical debt and yes it accrues interest.

The example was more personal and not that bad when you realize that the only price you paid is something you can’t stand to look at and also something that will take a long amount of time to fix. Like I said before it is just you working on it and as long as it works it’s fine…but what if you weren’t alone, say what if you were working in a team of 2 or 4 or perhaps a whole company amount. Then we have problems. Cause not only the debt is put upon others, but even money can be a problem if it is a company involved. 

There is also types of technical debt. Planned Technical Debt is meant to establish one presence in the market or gather feedback from customers, kinda like prototyping from my understanding. There is also Inadvertent Technical Debt when the developer is unsure of market requirements or aware of the architecture. 

Many things can cause technical debt to happen, such as poor management or the code not being reviewed well enough.  So to avoid such things it’s a good idea to 

  • Understand the Requirements
  • Understanding Decision Consequences
  • Supervising the Process

So be careful when coding a project as it may come to bite you in the future, so take into consideration the future you and help you out.

Be a Better Dev. (2020a, October 5). What is Technical Debt? (as a software developer). YouTube. https://youtu.be/2nDxKYIajoU?si=crpLGeoCewYZ_kEj

Eye on Tech. (2020b, October 7). What is Technical Debt and Why Does Tech Debt Matter?. YouTube. https://youtu.be/cdzUXv8SpjY?si=FHZ0Vl6ZVkhuSNeE

From the blog Debug Duck by debugducker and used with permission of the author. All other rights reserved by the author.

Psychology in Software Development

This week I discovered a blog that caught my attention. The blog discusses the incorporation of psychology into the process of software development. Spending extended periods seated, analyzing codes, searching for logical operations and function calls can exhaust our cognitive abilities. The fatigues could lead us to feel cloudy and have poor resolution. It goes deeper into the mind of a software developer mind on how one’s retain information, problem-solving approach, perceive the behavior and structure of what they’re building. It introduces study concept such as spaced repetition and interleaved practice that have been proven to enhance a person to learn new programming languages or frameworks. I believe that integrating psychological insights into software development can help enhance both individual mental well-being and professional skills.

The blog has eight topics, one of the first paragraph of the first one said,

“The project’s outcome hinged not on the technical challenges but on the interplay of personalities, communication styles, and the leadership structure within the team”.

“A team that communicates openly and respects each member’s input is more likely to solve problems effectively and innovate. On the other hand, a team mired in unresolved conflicts and poor communication can derail even the most promising projects.”

“A team that communicates openly and respects each member’s input is more likely to solve problems effectively and innovate. On the other hand, a team mired in unresolved conflicts and poor communication can derail even the most promising projects.”

“Linking these psychological insights to Agile practices offers a fascinating avenue for enhancing team-based methodologies. Agile’s iterative approach and emphasis on collaboration are well-suited to leverage the strengths of a psychologically savvy team.”

While managing my team during group activities on Methodology, I believe it is more beneficial for everyone to feel comfortable being their authentic selves rather than feeling anxious and reserved. I think the idea of Agile practices can assists them in expressing their ideas and feeling at ease within the group. Continuing to utilize Agile methods can result in increased efficiency and effective communication within a team to meet project deadlines.

“I recall an instance where a single line of feedback transformed a junior developer’s approach to coding. It wasn’t my code review that pointed out the errors; it was my remark about his unique problem-solving skills that made his eyes light up.” I concur that helping one another to solve a problem or code in an easier way because everyone have different background with coding. Therefore, feedback and mentoring is crucial when it comes to coding. One person code could load faster and less complicated than another. Positive reinforcement can amplify a person’s strengths.

Reading this blog helps me understand how psychology is integrated into software development. All of these aspects, such as team-work, leadership, problem-solving, cognitive biases, feedback, and coaching, can be advantageous when viewed through a psychological lens. It motivates us to improve ourselves and others by helping each other enhance our skills and cognitive abilities. Where we find inspiration daily.

Blog URL: https://betterprogramming.pub/integrating-psychology-into-software-development-c5f79fc8019e

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

(Week-1) Agile and Software Development

Agile is a set of values and principles that software developers and/or managers use to encourage a positive work environment that is efficient, and promotes a successful workflow.  Agile is becoming the gold standard for software development and programming, because it is inherently based on collaboration.  Not only does it encourage intense collaboration with members of the development team, but also the customers they are making the product for.  A core tenant of Agile is to not only keep the team on the same page, but also stay transparent with the customer and accommodate their every need with the product.  Here are some important values and principles Agile is based on: “Working software over comprehensive documentation”, “Simplicity”, “Responding to change”, “Customer collaboration”, “Human communication”, and last but not least: “Continuous attention to technical excellence”.  These aren’t the only values, but they are some of the most important ones. 

“An Ultimate Guide to Agile Software Development” is an informative video about Agile Software Development, by the YouTube channel Invensis Learning.  In the video, the narrator discusses how Agile is beneficial for teams specifically in the Software Development field.  They describe Agile Software Development as a “set of iterative software development methodologies in which requirements and solutions arise from collaboration among self-organizing cross-functional teams”.  This is very important to understanding Agile, and its uses in the workplace.  Agile allows for teams working on different parts of a project to stay on the same page, and not get ahead of their peers, while still having room for improvement and disagreement.  They also go on to explain how a company following Agile doesn’t necessarily mean there isn’t a manager coordinating these things, but it suggests that each sub-group should be able to handle their problems on their own.  The video also discusses the “Agile Software Development Life Cycle”, which touches on how Software Development teams should roughly plan out their work for a product.  The cycles can differ from company to company based on the amount of employees, type of work, customer expectations, etc.  But, the values and principles should stay the same to maximize Agile efficiency.  The Agile Life Cycle follows six important steps, Concept, Inception, Iteration, Release, Maintenance, and Retirement.

To sum up today’s topic, Agile is a set of values and principles primarily used by software developers to make the workplace much more efficient and stress-free.  Agile promotes customer collaboration, and in-house collaboration with peers to ensure the product is as perfect as possible.  Over time, most software development companies will come to develop these principles, as they have been proven to be one of the best work strategies.

LINK TO VIDEO: https://www.youtube.com/watch?v=Evl5f2CnR08

  • Elliot Benoit

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