Hello! For my second quarter blog, I read a separate blog written by Yung Han Jeong, titled “Spaghetti Deconstructed: Lessons from my first refactoring“. As its name suggests, this blog talks about Yung’s personal experiences and advice pertaining to refactoring. For those who don’t know, refactoring is essentially improving existing code in a way that doesn’t affect it’s functionality. This can be as simple as changing variable names, all the way to completely restructuring the program. In our class this semester, for a very large portion of what we will be doing, refactoring is an integral part of it. I would say at this point I am pretty comfortable with the topic, however I figured that I would like some sort of anecdotal, first-hand account of someone’s actual experiences with it, as everything we have been doing has been in a classroom setting. 

Yung’s blog recounts her experiences in refactoring some of her earliest code written when she was an entry-level developer, namely in her horror at how bad it used to be. It got her thinking about what she could have done to improve her code, which inspired her to blog about the biggest changes she thinks would make the difference (she provides four examples which she calls “pasta”, “sauce”, “meatballs”, and “cheese”, I don’t think I need to explain that). Firstly (pasta), she talks about the importance of having descriptive variable names. She argues that while it is enticing to have simple variable names that you might not see the need to go into detail about as you are familiar with the code, it is always worth the extra effort to either make them more descriptive, or to comment an explanation about all of them (or both!). Next (sauce), she hammers in the importance of commenting out the entirety of your code. It’s something all cs students have been pestered about endlessly, but it is one of the single most important things you can do to improve your code, being able to quickly understand what a method/class/etc. does saves so much time in the long run, outweighing the extra time you spend writing the comment. Her third point (meatballs) ties into this in that she recommends keeping most if not all debugging statements. She argues that once they served their purpose, they can simply be commented out and referenced in the future. Lastly (cheese), she emphasizes the importance of revisiting code “soon and often”. 

Admittedly, the advice Yung gives is pretty rudimentary. When I found this blog I thought it would talk about refactoring in the way we have in class, where we focus more on the structure side of things. However, reading this made me realize that this is very much refactoring as well. Sometimes the best thing you can do with your code is improve on the simple things, like naming schemes and comments, something Yung, an actual software dev, seems to find important enough to write a blog about. I am happy I found this blog; while I didn’t exactly learn anything ground-breaking, I realized that when refactoring, sometimes improving on the simple things is the best course of action to take. 

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

 Hello! For my second quarter blog, I read a separate blog written by Yung Han Jeong, titled “Spaghetti Deconstructed: Lessons from my first refactoring“. As its name suggests, this blog talks about Yung’s personal experiences and advice pertaining to refactoring. For those who don’t know, refactoring is essentially improving existing code in a way that doesn’t affect it’s functionality. This can be as simple as changing variable names, all the way to completely restructuring the program. In our class this semester, for a very large portion of what we will be doing, refactoring is an integral part of it. I would say at this point I am pretty comfortable with the topic, however I figured that I would like some sort of anecdotal, first-hand account of someone’s actual experiences with it, as everything we have been doing has been in a classroom setting. 

Yung’s blog recounts her experiences in refactoring some of her earliest code written when she was an entry-level developer, namely in her horror at how bad it used to be. It got her thinking about what she could have done to improve her code, which inspired her to blog about the biggest changes she thinks would make the difference (she provides four examples which she calls “pasta”, “sauce”, “meatballs”, and “cheese”, I don’t think I need to explain that). Firstly (pasta), she talks about the importance of having descriptive variable names. She argues that while it is enticing to have simple variable names that you might not see the need to go into detail about as you are familiar with the code, it is always worth the extra effort to either make them more descriptive, or to comment an explanation about all of them (or both!). Next (sauce), she hammers in the importance of commenting out the entirety of your code. It’s something all cs students have been pestered about endlessly, but it is one of the single most important things you can do to improve your code, being able to quickly understand what a method/class/etc. does saves so much time in the long run, outweighing the extra time you spend writing the comment. Her third point (meatballs) ties into this in that she recommends keeping most if not all debugging statements. She argues that once they served their purpose, they can simply be commented out and referenced in the future. Lastly (cheese), she emphasizes the importance of revisiting code “soon and often”. 

Admittedly, the advice Yung gives is pretty rudimentary. When I found this blog I thought it would talk about refactoring in the way we have in class, where we focus more on the structure side of things. However, reading this made me realize that this is very much refactoring as well. Sometimes the best thing you can do with your code is improve on the simple things, like naming schemes and comments, something Yung, an actual software dev, seems to find important enough to write a blog about. I am happy I found this blog; while I didn’t exactly learn anything ground-breaking, I realized that when refactoring, sometimes improving on the simple things is the best course of action to take. 

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

 Hello! For my second quarter blog, I read a separate blog written by Yung Han Jeong, titled “Spaghetti Deconstructed: Lessons from my first refactoring“. As its name suggests, this blog talks about Yung’s personal experiences and advice pertaining to refactoring. For those who don’t know, refactoring is essentially improving existing code in a way that doesn’t affect it’s functionality. This can be as simple as changing variable names, all the way to completely restructuring the program. In our class this semester, for a very large portion of what we will be doing, refactoring is an integral part of it. I would say at this point I am pretty comfortable with the topic, however I figured that I would like some sort of anecdotal, first-hand account of someone’s actual experiences with it, as everything we have been doing has been in a classroom setting. 

Yung’s blog recounts her experiences in refactoring some of her earliest code written when she was an entry-level developer, namely in her horror at how bad it used to be. It got her thinking about what she could have done to improve her code, which inspired her to blog about the biggest changes she thinks would make the difference (she provides four examples which she calls “pasta”, “sauce”, “meatballs”, and “cheese”, I don’t think I need to explain that). Firstly (pasta), she talks about the importance of having descriptive variable names. Next (sauce), she hammers in the importance of commenting out the entirety of your code. It’s something all cs students have been pestered about endlessly, but it is one of the single most important things you can do to improve your code, being able to quickly understand what a method/class/etc. does saves so much time in the long run, outweighing the extra time you spend writing the comment. Her third point (meatballs) ties into this in that she recommends keeping most if not all debugging statements. She argues that once they served their purpose, they can simply be commented out and referenced in the future. Lastly (cheese), she emphasizes the importance of revisiting code “soon and often”. 

Admittedly, the advice Yung gives is pretty rudimentary. When I found this blog I thought it would talk about refactoring in the way we have in class, where we focus more on the structure side of things. However, reading this made me realize that this is very much refactoring as well. Sometimes the best thing you can do with your code is improve on the simple things, like naming schemes and comments, something Yung, an actual software dev, seems to find important enough to write a blog about. I am happy I found this blog; while I didn’t exactly learn anything ground-breaking, I realized that when refactoring, sometimes improving on the simple things is the best course of action to take. 

From the blog Joshua's Blog by Joshua D. and used with permission of the author. All other rights reserved by the author.

For this blog entry I decided to choose something related to Agile. In the blogpost, Agile Principles: The Complete Guide To All 12 Principles For 2025 written by Sean O’Connor, he goes over how Agile’s flexibility gives it real world benefits for businesses, development teams, and customers. Much like how with what we went over in class, Sean O’Connor explains that Agile’s strengths aren’t so much about speed of delivery of a product, but in it’s efficiency in producing a working project, with speed as positive byproduct. As someone who’s never been good at long term planning, what was explained in the blogpost really resonated with me. Things like catching problems early when it hasn’t become a core “feature” of the software, building what the customer actually needs rather then wasting time, and especially the part of creating quick wins, are some things that I value in a game plan. The blogpost then goes into 12 principles that makeup all Agile methodologies, a couple of which really stood out to me.

One of the principles was delivering working software frequently. I like the idea of real progress you can actually see and use, not just what it could potentially be. It’s nice when you get to see something that actually works early, even if it’s just a rough version. This approach makes more sense to me than spending weeks or months planning something that might not even be what was wanted, which is just a huge waste of time and energy. So to me being able to get instant feedback, learn faster, and fix problems before they turn into something major, is huge.

Another principle that ties into that is measuring progress by working software. That line really sums up Agile’s idea of “cutting out the chaff”. It’s easy to get caught up in planning, documentation, or presentations that sound good but don’t actually move the project forward. A working prototype says more than any report could. I think that same logic applies to class projects too, seeing your code actually run feels like a real measure of progress, not how well it’s outlined on paper.

The principle of simplicity, or “maximizing the amount of work not done,” also hit home for me. It’s about focusing on what truly matters and using just enough time and energy needed. I tend to overthink projects at the start, but this mindset reminds me that getting the essentials working is more productive than building unnecessary features. Fewer moving parts also means fewer ways for things to break (something I know all to well).

All in all, it’s reassuring to see that my “slacker mindset” can be the basis for something actually productive.

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

The Unified Modeling Language (UML) has been playing a part in software development for years as it provided a standardized visual language for modeling the structure of complex systems. But there have been questions about UML and whether it is still useful because the software industry has shifted towards more iterative, flexible Agile methodologies, there have been questions about the relevance of UML. But the article explains that if you look at it closer then UML remains a valuable asset, especially when leveraged appropriately in an Agile context. UML has four main strengths which include visualization, abstraction, standardization, and design documentation. Visualization means that UML diagrams offer a powerful way to visualize and document the static structure and dynamic behavior of a software system. Abstraction is when UML supports modeling at various levels of abstraction, from high-level conceptual diagrams to detailed design specifications. Standardization is since it is a widely-adopted industry standard, UML provides a common language that can be understood by software professionals worldwide. Finally, design documentation means that UML diagrams can serve as a valuable reference for documenting the design of a system, which can aid in maintenance, support, and future enhancements.

Using these strengths there are many ways that UML can make its way into Agile environments. The first is ideation and communication, UML can be particularly useful during the initial stages of an Agile project, quick, lightweight UML diagrams can help the team visualize and communicate their concepts, leading to a shared understanding before diving into implementation. Next is agile modeling, rather than a complex upfront design, Agile teams can adopt a modeling approach where they create diagrams as needed through their current sprints. The third is architectural blueprinting, UML can play a role in defining and documenting the overall system architecture. By having a high level model, teams can ensure consistency and maintainability as the system evolves over time. The final one is knowledge capture and transfer. UML diagrams can serve as pieces for capturing and transferring info, particularly when gaining new team members or supporting the system in production.

The reason I chose this blog post to talk about is because we just recently did an assignment on UML and have talked a lot about it. During this time I always wondered why it was so important or what place it really had in a team of developers. Overall I believe that the blog itself did a great job at making me see why I was so wrong and what really was important. It can adapt so well over time and allows developers a way to help other members understand their work better and to communicate exactly what they are trying to accomplish. I plan to get better at using UML as a skill I can use in jobs to showcase Agile methodologies and hopefully it will help show not only a technical skill but also my ability to work more collaboratively in teams.

From the blog Thanas CS343 Blog by tlara1f9a6bfb54 and used with permission of the author. All other rights reserved by the author.

In my software construction, design, and architecture class we’ve focused a lot on (believe it or not), the design and structure of software. Software is typically quite intricate and designing it as efficiently and cleanly as possible is almost never accomplished the first time it is coded. “Code Refactoring and why you should refactor your code” by Lazar Nikolov is a great blog dedicated at explaining what refactoring is, why you should use it, and when you should use it.

Refactoring is just the process of identifying technical debt and code smells withing the existing program and modifying the code to be more optimized removing these issues without changing the user interface behavior. As Nikolov describes there are many objectives of refactoring such as increasing readability, maintainability, reusability, optimizing the performance, and enforcing code standards. There are many situations you should consider refactoring in. Such as DRY where you find and replace repetitive information with an abstraction that is less likely to change, or when working with someone else’s “bad” coding that you need to build on.

The key takeaway here is that no programmer does the job perfectly the first time. Programs constantly evolve and have changing specifications that must be met. A good programmer is one who can roll with those punches and change the code as needed. Our most recent homework assignment really focused in on this and had us refactor the code we we’re working with three different times each time using a different architecture. In doing so we learned each time how the previous code could be improves upon to function better and with less bugs even though the original code worked fine. Moving from the strategy pattern to the singleton pattern lastly to the simple factory pattern allowed us to see how each new version after refactoring solved a different problem from the previous. Even though they all worked fine we could see the optimization occurring.

Refactoring is certainly a concept I plan on carrying with me into the future. I’m not sure if there’s a good programmer out there that doesn’t use this concept constantly. Having the ability to constantly adapt my code to best suit it to not only its current task but any future ones that may arise is an incredibly good skill to have. I know it will help me not just as a student at Worcester State but as a professional software developer someday too.

From the blog CS@Worcester – DPCS Blog by Daniel Parker and used with permission of the author. All other rights reserved by the author.

My chosen source for my 2nd blog entry for CS-348 is: https://www.sciencedirect.com/science/article/pii/S0950584922001884#abs0001

Written in 2023, this article from ScienceDirect surrounds a set of 182 survey’s conducted on scrum team members to determine the influence maturity has on the effectiveness and success of a scrum team and their project. The relevance to seem is fairly self evident as college students can be a mixture of mature and immature which the article suggests could impact effectiveness of scrum teams in the classroom.

This leads me onto why I chose this article as my source, In an environment like our classroom, the maturity of the students and or even professor(s) involved can, as said in the relevance portion, could impact our scrum team effectiveness and efficiency. I decided this was a strong connection to make as people new to the scrum framework, cause while understanding scrum and knowing how it works is important, I do think team member maturity is important as well as it has effected my ability to work in teams in the past and be effective and efficient.

I like that this article provides a good explanation of scrum and what it’s advantages are, it gives context for those unfamiliar with scrum to understand where the article is headed, although I would argue you don’t need the context as the study this article dives into can most certainly apply to any kind of framework out there. As for reflecting on this material I want to pull back to where I mentioned the maturity of my teams in past group projects and tasks have most certainly effected the ability of myself and my team to be effective and efficient at completing our goals, this is initially why this material called out to me as I read it. Though as I read it, I started to compare those experiences with what we’re doing in CS-348 currently. While not working in scrum teams, our teams of 4 for working on our class exercises to learn scrum are a good comparison towards maturity’s impact on our ability to finish the work in a reasonable amount of time.
For example, my first team, we were decently good at getting our work done in a good period of time, but I will admit sometimes we could be a bit slow as we let our maturity slip up. Once we mixed the teams around I saw how much more maturity mattered as we all adjusted to the effectiveness of all our new team members. Some teams got slower, some got faster, while I’m not pinning the reason entirely on maturity, I do think it’s a large influence. I also think its important that our teams got swapped around not just so we learned to work with new people but so we could learn to properly adjust and adapt to our changing environments.

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

Hello everyone,

This week’s blog will cover Unified Modeling Language (UML) as this was a topic we recently covered in class and it was something that really left me in awe after learning about it so I wanted to write a blog about it. After finishing the homework about UML I realized how important of a tool it is for software developers and system designers. 

The author starts off the blog by giving a table of content to the reader. This allows them to get familiar with the structure of the blog, what it has to offer, and they can also jump on to a specific part that they want to read specifically. So UML is a standard visual language used in Software Engineering to model and design software systems. It helps developers, analysts, and stakeholders understand system structure, behavior, and interactions through diagrams. These can be extremely useful to people who are not familiar with coding and want to understand what the code does without being confused and lost when looking at it. The blog describes the purpose, significance, and the different types of UML, while also giving good advice and examples. On top of these, the author keeps a balance of technical explanation and keeping it simple for new learners. Later on the blog, he explains how UML closes the gap between technical and non-technical project members by providing a diagram which showcases the whole structure of the code and how everything is connected with each other. The article puts the history of how UML was created in the 1990s, and how the Object Management Group (OMG) took it as a standard. What I enjoy the most about this section is that it emphasizes why it is important, it improves communication, reduces misunderstanding, and helps in identifying design defects early. The blog then explains the various kinds of UML diagrams, like Class Diagrams, Use Case Diagrams, Sequence Diagrams, and Activity Diagrams. Both are discussed in detail along with their application, so it would be easy to understand when to use one over the other. The author also offers a step-by-step hands-on guide to creating UML diagrams, from deciding the purpose to using tools like Lucidchart.  The blog also has a dedicated section where it encourages the reader to practice and learn how to use UML. He states that it can be tricky at first, but with enough practice it will become easier to anyone. You can start off small and eventually you will get comfortable using UML when creating bigger projects

In conclusion, this blog was very informative and pertaining to my learning goals currently. Not only does the author describe what UML is, but he also takes readers through its actual uses, best practices, and even its limitations. Having this balance allows me to view UML as more than a diagramming scheme. It means thinking and planning effectively beforehand before starting to code..

Source: https://www.theknowledgeacademy.com/blog/unified-modeling-language/

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