Category Archives: @Week10

To Be Agile

I recently came across a blog post on LucidSpark titled What Is Agile Methodology? that explains the basics of Agile and its role in modern software development. Agile is a project management and software development approach that emphasizes flexibility, collaboration, and customer feedback. The methodology breaks down large projects into smaller, manageable chunks called sprints—usually lasting a few weeks. This approach allows teams to adapt quickly to changes, make continuous improvements, and deliver working software regularly. The blog goes on to explain the Agile Manifesto, which highlights values like individuals and interactions over processes and tools, and customer collaboration over contract negotiation.

I chose this article because it offers a clear, easy-to-understand explanation of Agile, a methodology that I’ve heard about a lot in my software engineering classes and in discussions about software projects. I wanted to learn more about it and see how it’s used in real-world development, especially since I might be using it in some of my future group projects. The post helped clarify some of the concepts I’ve learned in theory and gave me a better understanding of how Agile works in practice.

One of the most interesting takeaways from this article was the emphasis on adaptability. In traditional project management, there’s often a lot of upfront planning, but Agile is all about being able to adjust quickly to changes—whether that’s changes in customer requirements or new technologies. I realized that in software development, the ability to pivot and change direction is just as important as having a solid plan in the first place. This idea of “failing fast” and improving iteratively really resonated with me. I’ve noticed that when I work on assignments or personal projects, sometimes things don’t go as planned, and it’s frustrating to try and stick to a rigid approach. Agile’s flexibility seems like a better way to handle those situations.

Another part of the article that stood out was the focus on collaboration. Agile teams work closely together and communicate regularly, which is different from the more isolated approach I’ve seen in some projects where team members work separately and only come together at milestones. The post explained how frequent communication, daily stand-ups, and collaboration with customers can help create better products and avoid misunderstandings. This is something I want to keep in mind for group projects, especially in coding assignments where communication can make a huge difference in the quality of the work.

In my future career, I plan to apply what I’ve learned by adopting some Agile practices in my own projects. I want to be able emphasize collaboration and open communication in group assignments, which could lead to more efficient and effective teamwork.

Resource:

https://lucidspark.com/blog/what-is-agile-methodology

From the blog Computer Science From a Basketball Fan by Brandon Njuguna and used with permission of the author. All other rights reserved by the author.

Smelly and Debt

I recently read an article on Opsera titled What Is Code Smell? that explores the concept of code smells and how they relate to technical debt. The article explains that code smells are indicators of deeper issues in software design, like redundant code, overly complex functions, or lack of proper documentation. While these smells don’t necessarily cause bugs, they can make the code harder to maintain or extend in the future. Technical debt, on the other hand, refers to the trade-off between short-term efficiency and long-term code quality. It’s like borrowing from the future to meet deadlines now, but it eventually has to be repaid with interest—usually in the form of extra work to fix the issues caused by the shortcuts taken.

I chose this resource because it gives a practical explanation of two topics that I’ve encountered in my software engineering classes: design smells and technical debt. These are concepts that seemed theoretical at first, but this article helped me understand how they show up in real-world projects. As I start working on my own coding assignments, I can see how these issues might impact my projects if I don’t pay attention to them early on.

The article made me realize just how crucial it is to identify and address code smells early in the development process. For example, the article points out that long methods and duplicated code can be a sign of poor design that will slow down future changes. At first, I thought that refactoring or improving code design was something only necessary when a project was nearing completion. But now I understand that addressing these problems early can save a lot of time and effort in the long run.

What really stood out to me was the connection between technical debt and long-term project maintenance. As a student, it’s easy to think that as long as the code works, it’s good enough. But this article emphasized that taking shortcuts to meet deadlines may create technical debt that leads to problems later, such as bugs or a codebase that’s difficult to work with. I’ve already seen this in my own projects—trying to push through a solution quickly, only to realize later that the code is harder to manage than I expected.

In the future, I plan to pay more attention to clean code practices. I’ll aim to refactor code regularly and avoid taking shortcuts that might seem like a quick fix but could lead to bigger problems. This approach will not only improve my coding skills but also make my future projects more maintainable.

Resource:

What Is Code Smell? – Opsera Blog

From the blog Computer Science From a Basketball Fan by Brandon Njuguna and used with permission of the author. All other rights reserved by the author.

Reflect as you work

So far, of all the patterns I’ve encountered, Reflect as you work seems to be the one that can be most easily tracked in a more concrete form! This is very interesting to me because many of the other patterns deal with almost abstract topics, whether it be considering how you yourself grow, or how to approach learning, it is usually hard to determine your growth, but Reflect as you work makes a tangible ‘map’ that someone can reference!

Reflecting as you work, to put it simply, is the process of making some sort of way to track what kinds of things you are doing. It seems like it could be a map of your skills and process, or it could be a variety of other things. But essentially, as long as you are making a way to visualize the types of skills you have, it is a way for you to go over each of those different skills and see if things are working, or if they are counterproductive. An example that was made was that if someone made a map of these skills, they can go over them as time goes on, and though this process or that approach might have worked in the past, it might need to be updated, or transformed all together.

Overall, this is something that I have never really thought about doing, but it seems incredibly helpful. No doubt, if I made a map of my own skills to reflect on, it would make it blatantly obvious to see which things I am lacking, or even better, which things to improve on. Already, I have an idea that my algorithm skills are a bit lacking, but I am sure that there are other things that I can improve upon as well. With the creation of a visualizer, I can much more easily reflect on the type of work I am doing, and overtime, I can also see if the things I am doing are good, or a bit flawed. I know for a fact, that if I looked back at my older works, I’d be complete horrified by some of the ways I fixed problems, and I know that in the future, it will be the same! This process of reflection is usually just internal, but with a concrete tool to use, it would probably be so, so much easier.

From the blog CS@Worcester – Bored Coding by iisbor and used with permission of the author. All other rights reserved by the author.

Unleash your enthusiasm!

As I was going through the patterns, I came across the Unleash your enthusiasm. At first, I didn’t consider it too much, and took it at face value, and as it was explaining the pattern, I was frankly confused. From my perspective, it appeared like the author was trying to curb a bit of enthusiasm rather than nurture it, but there is actually more nuance to the whole pattern than it seems. Rather than the pattern being all about your own enthusiasm, I think that this pattern has much more connections with the team aspect.

The pattern does briefly go over this, but if you’re anything like me, it might have flown over your head, but I believe that this key fact is very important to processing the pattern. Mainly, if team morale is low, or if they aren’t as accepting, there are other ways to unleash your enthusiasm without compromising the team dynamic! I believe that out of the few patterns I’ve gone over so far, this pattern is the most grey! There is no definite answer to each and every team that you might join in, because there is just no ‘correct’ way to deal with people as a whole! It is very important to adjust your own standards, and thus, adjust your own enthusiasm on a case by case basis! Some people might be more receptive, while others might not be as receptive, but either way, it is important to find out beneficial ways to unleash your enthusiasm.

The pattern has a small action portion, but I believe that there are much more ways to show your enthusiasm! I think that if your team is not as receptive, you can show your enthusiasm by finding peers, or other like-minded communities! And if your team does welcome it, then there is no harm in showing the interest you have! Being able to find healthy ways to channel your enthusiasm will benefit not just yourself, but the whole team! As it even states, unleashing your enthusiasm will ensure that new perspectives aren’t missed, and with plenty of questions, everyone will grow! Staying silent would only be a detriment, because if you spot something that others might not, or if you keep questions to yourself, you won’t be able to reinforce ideas and also actively prevent yourself from learning! 

From the blog CS@Worcester – Bored Coding by iisbor and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern Review #6: Practice, Practice, Practice

The people we know as masters don’t devote themselvesto their particular skill just to get better at it. The truth is,they love to practice—and because of this they do getbetter. And then to complete the circle, the better they get the more they enjoy performing the basic moves over andover again.—George Leonard, Mastery Each one … Continue reading Apprenticeship Pattern Review #6: Practice, Practice, Practice →

From the blog CS@Worcester – Shams's Bits and Bytes by Shams Al Farees and used with permission of the author. All other rights reserved by the author.