When I first heard the phrase “technical debt,” I honestly thought it was just a fancy developer way of saying “bad code.” But after reading Atlassian’s article “Technical Debt: What It Is and How to Manage It,” I realized it’s way deeper than that. The article explains technical debt as the cost of choosing a quick solution now instead of a cleaner, long-term one. This can come from rushing to meet deadlines, adding features without proper planning, skipping tests, or even just writing code before fully understanding the problem. What I liked about this resource is that it breaks the topic down in a way that makes sense, showing how debt doesn’t always come from laziness, sometimes it’s just the reality of working in fast-paced software development.

I picked this article because technical debt is something we’ve basically been talking about throughout CS-348, even if we didn’t always call it that. Whether it’s writing maintainable code, designing clean architecture, or keeping up with version control, everything connects back to avoiding unnecessary debt. I’ve heard instructors and even classmates say, “We’ll fix that later,” and this article made me understand the impact behind that mindset. It stood out to me because it not only defined the problem but walked through how teams can recognize debt early and avoid letting it build up until it becomes overwhelming.

Reading this article made me realize how much technical debt affects the entire development process, not just the code. It slows teams down, creates frustration, and makes simple tasks more complicated than they should be. One part that hit me was how the article described debt snowballing over time. It reminded me of school assignments: if you ignore a confusing part early on, it always comes back to make the whole project harder. Another point I loved was the idea of being honest about debt instead of acting like it doesn’t exist. Communication is a big deal in development, and the article made that very clear.

Moving forward, I’m definitely going to be more intentional about how I write and manage code. Instead of rushing through things just to “get it done,” I want to slow down and think about how my decisions today could affect future work, both for me and for anyone else who touches the code. Good documentation, regular refactoring, testing early, and asking questions when something feels off are all habits I want to bring into my future career. Understanding technical debt helped me see software development as a long game, and being aware of these trade-offs will help me build better, cleaner projects in the future.

Source:

https://www.atlassian.com/agile/software-development/technical-debt

From the blog CS@Worcester – Circuit Star | Tech & Business Insights by Queenstar Kyere Gyamfi and used with permission of the author. All other rights reserved by the author.

For this week’s self-directed professional development, I explored the topic of choosing open source licenses, which is a fundamental but often overlooked part of releasing software. I based my reading on ChooseALicense.com and supporting resources that explain how permissive licenses, copyleft licenses, and public domain-style licenses differ. What I found most interesting is how a license doesn’t just define legal rules — it reflects the values, intentions, and goals of a developer or a team. Software licensing shapes how a project evolves, how a community forms, and how contributions are handled over time.

Open source licenses fall into a few broad categories. Permissive licenses like MIT or Apache 2.0 give users almost complete freedom to reuse the code, even in closed-source commercial products. Copyleft licenses like GPL ensure that any derivative work must remain open source under the same license. And options like the Unlicense or CC0 place code essentially in the public domain, allowing anyone to use it with zero restrictions. Before this week, I assumed licensing was just a legal formality, but now I understand how strongly each license type influences collaboration and long-term project direction.

I chose this topic because licensing is directly connected to the work we do in Software Process, especially when we talk about transparency, collaboration, and project ownership. As future developers, we will eventually publish our own tools, libraries, or contributions. Knowing how to license our work is part of being a responsible member of the open source community. Many people assume that posting code publicly means anyone can use it, but without a license, nobody can legally copy, modify, or reuse it. That detail alone made this topic worth exploring, and it helped me rethink how important explicit permissions are.

One thing I learned is that choosing a license is really about choosing a philosophy. If a developer wants to share knowledge broadly, enable commercial use, and reduce friction for adoption, a permissive license makes sense. If the goal is to ensure the code stays free for everyone and cannot be closed off by others, a copyleft license protects that intention. The reading made me think carefully about what I would want if I released a personal project. Personally, I lean toward permissive licenses because I want people to build on my work without worrying about legal constraints. But I also understand why larger community-focused projects might choose GPL to preserve openness.

Going forward, I expect licensing to be something I pay more attention to in both school projects and professional work. As software engineers, we’re not just writing code; we’re shaping how others can interact with it. Licensing is part of that responsibility. This topic helped me better appreciate the intersection between technology, ethics, creativity, and law — and it reminded me that releasing software is more than just pushing code to GitHub; it’s about defining how that code fits into the larger ecosystem of open source development.

From the blog CS@Worcester – Life of Chris by Christian Oboh and used with permission of the author. All other rights reserved by the author.

Version control is something I’ve used before in classes, but I never fully understood its importance until I read the Atlassian article, “What is Version Control?” (https://www.atlassian.com/git/tutorials/what-is-version-control). I selected this resource because Atlassian explains technical concepts in a way that feels practical and industry-focused, which fits perfectly with what we are learning in CS-348. Since this course emphasizes collaboration, documentation, project organization, and professional tools, I wanted to learn more about how version control actually supports real-world software development.

The article defines version control as the practice of tracking and managing changes to code. What stood out to me is that version control isn’t just for “saving work”, it’s a full system that captures every change, who made it, when it was made, and why. Atlassian highlights how this creates a long-term project history that developers can search through, compare, or revert. This directly connects to our CS-348 topics like software maintenance, project management, documentation standards, and team collaboration, because version control supports all of these practices behind the scenes.

The resource also explains how version control allows teams to work on separate branches, make experimental changes, fix bugs, or build features without interfering with one another. This connected with my experience in this course because when we work on group projects or assignments, version control prevents us from overwriting each other’s work. The article also discusses merge conflicts, and reading about it made me feel better about the moments when I’ve run into conflicts myself. Instead of seeing them as mistakes, the article made me realize they are a normal part of teamwork and software development.

One major takeaway for me was the idea of traceability. Every commit tells a story, not just about the code, but about decisions, goals, and teamwork. This encouraged me to treat commit messages more seriously so that my future teammates (or even future me) can understand the purpose behind changes. The article made me realize that version control isn’t just a technical tool; it is a communication tool. This is something I didn’t appreciate before reading it.

This resource affected how I view my future practice because version control is required in almost every professional software environment. Reading about how teams rely on it to avoid lost work, manage parallel development, and maintain high-quality software helped me understand why CS-348 emphasizes collaboration tools, project organization, and documentation. Going forward, I plan to use branching more intentionally, commit more frequently, and write clearer commit messages. I also want to apply what I learned outside of class by using version control for my personal and club-related tech projects.

Overall, this article helped me connect the technical skills we practice in CS-348 to how real development teams work. It showed me that version control supports not just code, but communication, teamwork, and professionalism — all skills I want to continue developing.

Source

Atlassian. What is version control. Retrieved from https://www.atlassian.com/git/tutorials/what-is-version-control

From the blog CS@Worcester – Circuit Star | Tech & Business Insights by Queenstar Kyere Gyamfi and used with permission of the author. All other rights reserved by the author.

Hello everyone, and welcome to my blog entry for this week! Technically, not a blog entry since I am just re-doing the one, I previously posted.

Last weekend, I listened to the podcast from the Coding Blocks Podcast (codingblocks.net). I’ve always been curious about how experienced developers structure their code to make it easier to maintain and scale, so this seemed like the perfect topic to explore. The episode focused on design patterns, specifically the three main categories: Creational, Structural, and Behavioral. Listening to it gave me a new appreciation for how these patterns help solve common software design problems and make codebases more adaptable over time.

Summary of the Podcast

The episode, which runs for about 50 minutes, features developers Michael Outlaw, Joe Zack, and Allen Underwood discussing how design patterns provide reusable solutions to recurring challenges in software development. They describe Creational patterns as those that handle object creation in a flexible way, Structural patterns as those that organize and relate classes and objects, and Behavioral patterns as those that define how objects communicate and share responsibilities.

They shared several examples, such as the Factory Method (a Creational pattern used to create objects without specifying exact classes), the Adapter (a Structural pattern that allows incompatible interfaces to work together), and the Observer (a Behavioral pattern that lets one object notify others when its state changes). What I liked most was how the hosts emphasized that patterns aren’t rigid rules, they’re practical tools developers use to make their code more consistent and easier to maintain.

Why I Selected This Resource

I chose this podcast because I wanted to deepen my understanding of how large software systems are organized. I’ve often heard about design patterns being essential for professional software engineering, but I never had a clear idea of how they were actually applied. The podcast stood out because it explained patterns in an approachable way, connecting them to real-world examples like GUI systems, game engines, and web frameworks. It helped me see that these patterns appear everywhere from database connections to event handling, and that learning them is key to writing scalable, professional-grade code.

Personal Reflections: What I Learned

After listening, I realized that design patterns are really about thinking ahead.

• Creational patterns reminded me that object creation should be flexible, not hard-coded.
• Structural patterns showed me how organizing relationships properly can make systems easier to extend.
• Behavioral patterns highlighted the importance of communication between objects and how good design reduces dependencies.

What stood out to me most was how design patterns encourage better decision-making. They don’t just make code work, they make it work better over time.

Application to Future Practice

Moving forward, I plan to start identifying patterns in the code I write. I want to experiment with the Singleton pattern for managing shared resources, like configuration files, and use the Strategy pattern when implementing algorithms that can be swapped dynamically. Understanding these patterns will help me approach programming challenges with more structure and confidence, and will prepare me for real-world software development where scalability and design quality matter most.

Citation / Link

Outlaw, Michael; Zack, Joe; and Underwood, Allen. Design Patterns Explained. Coding Blocks Podcast, 2019. Available online at codingblocks.net.

This podcast helped me see how Creational, Structural, and Behavioral design patterns provide a common language for building better software. Listening to it last weekend gave me new insights into how thoughtful design decisions can make a project more flexible, maintainable, and ready for growth.

From the blog CS@Worcester – Rick’s Software Journal by RickDjouwe1 and used with permission of the author. All other rights reserved by the author.

For my second self-directed professional development blog, I read an article from freeCodeCamp titled What is Software Testing? A Beginner’s Guide. The post explains what software testing really is, why it’s essential in the development process, and breaks down the different types of testing that developers use to make sure software works as intended.

The article starts with a simple but powerful definition: testing is the process of making sure your software works the way it should. It then describes several types of testing like unit, integration, system, and acceptance testing and explains how each one focuses on different levels of a program. It also introduces core testing principles such as “testing shows the presence of defects, not their absence” and “exhaustive testing is impossible.” Those ideas really stood out to me because they show that testing isn’t about proving perfection it’s about discovering what still needs to be improved.

I chose this article because, as a computer science student and IT/helpdesk worker, I deal with troubleshooting and debugging almost daily. I’ve always seen testing as something that happens after coding, but this article completely changed that mindset. It made me realize that testing is an ongoing part of development, not a one-time task before deployment. It’s a process that ensures software is not only functional but also reliable for real users.

What I found most interesting was how the author connected testing to collaboration and communication. Writing good test cases is like writing good documentation, it helps other developers understand what the software should do. The idea of “testing early and often” also makes a lot of sense. By catching issues early in the process, developers can save time, reduce costs, and prevent bigger headaches later on.

Reading this made me reflect on my own coding habits. I’ve had moments in class where my code worked “most of the time,” but I didn’t always test for edge cases or unexpected inputs. Moving forward, I plan to write more tests for my own projects, even simple ones. Whether it’s a class assignment, a group project, or a personal program, I now see testing as a chance to build confidence in my work and improve how I think about quality.

Overall, this article helped me understand that software testing isn’t just about finding bugs it’s about building better software. It’s a mindset that values curiosity, patience, and teamwork. By applying these lessons, I’ll be better prepared not only to write code that works but to deliver software that lasts.

***The link to the article is in the first paragraph***

From the blog CS@Worcester – Circuit Star | Tech & Business Insights by Queenstar Kyere Gyamfi and used with permission of the author. All other rights reserved by the author.

Hello everyone, welcome back to my blog! In my previous post, I explored object-oriented design basics and the importance of UML diagrams for understanding class relationships. This week, I applied that knowledge to a practical assignment by refactoring the Duck Simulator project using several design patterns, and I want to share what I learned from the process.

Introduction

UML diagrams provide a visual blueprint for software systems, helping developers understand relationships, dependencies, and responsibilities of different classes. While useful on their own, combining UML with design patterns allows us to translate those visual models into flexible, reusable, and maintainable code. In the Duck Simulator project, I used UML to identify repetitive behavior and then applied Strategy, Singleton, and Factory patterns to improve the system’s design.

Using UML to Identify Problems

Originally, the Duck Simulator consisted of an abstract Duck class and subclasses like MallardDuck, RedHeadDuck, RubberDuck, and DecoyDuck. Each duck implemented its own fly and quack methods. My UML class diagram made it clear that this design was repetitive: multiple subclasses had similar or identical behaviors. This repetition violates the DRY (Don’t Repeat Yourself) principle and makes the system harder to maintain or extend. The diagrams highlighted the exact areas where behavior abstraction could be applied, providing a clear roadmap for refactoring.

Applying the Strategy Pattern

The first refactor I implemented was the Strategy Pattern, which separates the fly and quack behaviors into FlyBehavior and QuackBehavior interfaces. Each duck is assigned a behavior object rather than hard-coding methods. Using UML, I could visualize how Duck classes now depend on behavior interfaces, not concrete implementations. For example, RubberDuck now uses the Squeak behavior, and DecoyDuck uses MuteQuack. This change made it easy to swap behaviors dynamically and reduced duplicated code across subclasses.

Using the Singleton Pattern

Next, I noticed that all ducks shared identical behaviors like FlyWithWings and Quack. To avoid creating multiple unnecessary instances, I applied the Singleton Pattern. UML helped illustrate that each behavior class has a static instance and a getInstance() method. This ensured that ducks reused the same behavior object, saving memory and improving consistency.

Implementing the Simple Factory Pattern

Finally, I created a DuckFactory to centralize the creation of ducks with their associated behaviors. UML shows a clear dependency from the simulator to the factory, encapsulating construction logic and removing manual behavior assignments in the simulator. This simplified code maintenance and improved readability, while maintaining all Strategy and Singleton benefits.

Reflection

This assignment reinforced how UML and design patterns complement each other. The diagrams helped me see problems in the design, and patterns provided proven solutions. After completing the refactor, the Duck Simulator is now modular, maintainable, and extensible. I can confidently add new duck types or behaviors without touching existing code. Personally, I learned that UML isn’t just documentation, it’s a tool that guides better design and code structure.

Resources

While exploring this assignment, I also reviewed a great resource that breaks down the concepts from Head First Design Patterns in a clear and structured way. You can find it here on GitHub. It helped me connect UML representations with real-world code implementations, especially when applying the Strategy Pattern in my Duck Simulator project.

From the blog CS@Worcester – Rick’s Software Journal by RickDjouwe1 and used with permission of the author. All other rights reserved by the author.

The GeeksforGeeks article “Coding Standards and Guidelines” highlights the importance of writing code that is clean and consistent. It also underlines the need for code that is easy to understand. It explains that coding standards are a set of rules and conventions that help developers maintain clarity and quality across a project. These standards cover areas such as naming conventions, indentation, code structure, comments, and documentation. The article emphasizes that following standards is not about limiting creativity. It is about making sure that everyone working on a project can easily read and maintain the code. It also points out that coding guidelines help prevent errors. They make debugging easier. They ensure that software projects remain manageable as they grow.

I chose this resource because I’ve noticed how quickly group projects can become messy. Each person having a different coding style contributes to this messiness. I’ve always cared about writing code that works. I’ve started realizing that how the code looks and reads is just as important. This is especially true in team environments. This article stood out to me because it clearly explained the purpose behind coding standards.

One key lesson I learned from this article is that consistency builds trust among developers. When everyone follows the same structure, it becomes easier to understand, review, and modify code written by others. The article also reinforced the idea that good code should be self-explanatory. For example, meaningful variable names like totalPrice or userCount communicate intent better than short, unclear ones like x or val. I also learned how proper indentation and spacing make code more readable and reduce the risk of logic errors that come from misaligned statements or missing braces.

Reading this resource made me reflect on my own coding habits. Sometimes, when I’m rushing to finish an assignment, I skip comments or mix naming styles without thinking about how confusing it might be later. Now, I see that writing clean code is an investment as it saves time when debugging and helps others understand what I meant. I also want to use tools like linters and formatters to automatically enforce standards in my projects.

Overall, this article helped me understand that coding standards are not about perfection but they are about communication. Clean, organized code reflects professionalism and respect for the next person who will read it. It reminded me that in software process management, technical skills and teamwork go hand in hand. Writing code that others can easily follow is one of the best ways to contribute to a project’s long-term success.

LINK TO RESOURCE:

https://www.geeksforgeeks.org/software-engineering/coding-standards-and-guidelines/

From the blog CS@Worcester – Circuit Star | Tech & Business Insights by Queenstar Kyere Gyamfi and used with permission of the author. All other rights reserved by the author.

Blessings James starts the article by advising readers that starting it may be difficult but to trust the process because the feeling after you accomplish your task is another feeling entirely. Her favorite project was working on a to-do list application with a backend using Python. It was difficult for her to work while also being data efficient. By doing research she was able to find a scalable model that worked. She also discovered some libraries including Flask-login that would do a lot of the heavy lifting. This was key for security which is often overlooked. Debugging is always a problem that comes up but she was able to gracefully fix them. API design was also a key feature wired on but swagger made it a lot easier. 

Reading this article gave me a lot of insight into someone working in the backend for a real company. There were some similarities to what were doing now including swagger. Swagger seems like the for the API design. We haven’t used all the features of Swagger but using Swagger Preview did help when doing assignments and homework. Our code was automatically able to be seen updated. One thing that interested me was Flask-login. I didn’t know you could use outside libraries but it makes sense if it is open to the public anyone can use it. It can save time by being able to use different libraries and cut your workload by half. Reading that article there was a big emphasis on security and I feel at times is overlooked. You have seen with a lot of companies when it is overlooked the outcomes are drastic. It becoming a bigger issue every day and security should be the first task on everyone’s list.

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

The article provides a clear overview of the current state of copyright law as it pertains to AI. Traditionally, copyright laws have protected works created by human authors, but with the rise of AI-generated content, it led me to ask: “can an AI be considered an author in its own right, or does the copyright belong to the human who programmed the AI, or the user who directed its output?” I learned that, under current law, AI cannot be considered an author in its own right, and the copyright typically belongs to the human creator or the user of the AI. This reflects a fundamental principle that we explore in our class, especially when considering software licenses. For example, when choosing a license for a software project, it is essential to understand the ownership of contributions and the rights of the contributors.

I selected this resource because the legal implications of AI are an area of particular interest to me, especially as AI continues to grow in influence and application across various industries. In one of my other classes, Computing Ethics, we talked about the ethical responsibilities and legal dilemmas surrounding the use of AI. The context being medical fields or business, how would the use of AI affect the users using it. This article connects those themes by highlighting the legal aspects of AI usage and authorship, which I had not fully considered before. It helped me understand that as AI technology becomes more sophisticated, the law may need to adapt to address new challenges.

By exploring “Copyrights in AI: Legal Overview” and reflecting on the licensing aspects discussed in my homework, I have gained a deeper understanding of how AI-related legal issues intersect with software licensing. In our Copyright and Licensing Homework, we focus on understanding different licensing models and the implications they have on the use and distribution of software so understanding who owns the rights to AI-generated works is critical to deciding how those works can be shared, modified, or distributed.

I expect to apply this knowledge when working with software projects, ensuring that the terms and conditions of any AI tools or systems used are clearly defined. As AI continues to grow in capabilities and its integration into software development increases, I believe this knowledge will be essential to navigating the complex legal landscape.

Link to the resource: HackerNoon article: Copyrights in AI: Legal Overview

From the blog SoftwareDiary by Oanh Nguyen and used with permission of the author. All other rights reserved by the author.

The post highlights key aspects of improving developer workflows. It starts by discussing the importance of having fast feedback loops, meaning developers should quickly see the results of their code changes. This post introduces tools like Vercel’s platform, which makes it easy to preview, test, and deploy changes almost instantly. Another focus is on collaboration, emphasizing how tools like GitHub help teams share work and review code seamlessly. It wraps up by stressing the value of automation, like setting up CI/CD pipelines, to reduce repetitive tasks and ensure consistent quality in the codebase.

I chose this post because workflow optimization feels like an essential skill for any developer, even beginners. Sometimes I get stuck on repetitive tasks or wait too long to test my code changes, which can be frustrating. This post seemed like a good way to learn how experienced developers streamline their processes. Also, tools like GitHub and CI/CD were mentioned in class, so I wanted to understand them better.

The main thing I learned is how fast feedback loops can save a lot of time and frustration. For example, using tools like Vercel lets developers instantly preview their changes in a live environment, so they don’t have to guess if their code works. I also learned how CI/CD pipelines automate testing and deployment, which not only saves time but also reduces the risk of errors. I realized that these tools make a developer’s life easier, but they also require some setup and understanding, which I’m excited to learn more about. Another cool takeaway was how much collaboration matters in a developer’s workflow. I’ve used GitHub for simple projects, but the blog post made me realize how powerful it can be when teams use it for pull requests, code reviews, and tracking changes.

This blog post made me want to improve my own workflow by setting up faster feedback systems, even for small projects. I also plan to explore tools like GitHub Actions to try basic automation for testing. In the future, I hope to use these techniques to work more effectively on team projects and avoid common frustrations like repetitive tasks.

Resource:

https://vercel.com/blog/improving-developer-workflow

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.