Category Archives: Software Development

Understanding Technical Debt: Why It Actually Matters More Than We Think

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.

Blog 4 Code Review

I am Dipesh Bhatta, and I am writing this blog entry for CS-348 Software Process Management for Blog Quarter 4. I chose to write about code review and how it connects to software process management. My chosen resource is an article titled “What is a Code Review?” from Atlassian (https://www.atlassian.com/agile/software-development/code-reviews). This passage explains what code review is, why it matters in software development, and how teams use it to maintain quality, consistency, and shared understanding across a project.

The passage defines code review as the practice of examining another developer’s work before it becomes part of the main codebase. It emphasizes that code review is more than a bug-finding activity. It helps improve readability, structure, naming, and overall maintainability. One important idea from the article is that code review serves as a communication channel. When developers submit changes for review, they are also sharing their reasoning and thought process with the team. This allows everyone to stay aligned and ensures that the project follows a predictable and well-managed workflow. These ideas directly connect to the concepts of structured processes and shared ownership that we learn in CS-348.

I chose this resource because code review is a key part of modern software process management. Throughout the semester, we used Git, branches, merge requests, and clean code practices. Code review brings all of these together into a single process that supports collaboration and project organization. Understanding how professional teams use code review helped me see the purpose behind good habits such as writing meaningful commit messages, keeping changes small, and separating different tasks into separate branches. These practices make reviews easier and prevent confusion later.

Another valuable point from the article is how code review helps reduce technical debt early. Small issues, such as unclear variable names or overly complex functions, may not break the program right away, but they make the code harder to maintain. Code review allows teams to fix these problems before they grow. This is especially important in long-term projects, where small mistakes can become costly if left unchecked.

The article also highlights the importance of giving feedback respectfully. Suggestions like “Could we simplify this part?” or “What do you think about renaming this variable?” create a more positive and productive review environment. I experienced this in class as well. The way feedback is written affects how teammates respond and how smoothly the discussion goes. Good communication makes the whole team stronger.

In short, code review is an essential part of software process management. It supports collaboration, improves quality, and keeps the codebase organized. Through Blog Quarter 4, I strengthened my understanding of reviews, communication, and clean coding practices that will benefit me in future projects and my career.

From the blog CS@Worcester – dipeshbhattaprofile by Dipesh Bhatta and used with permission of the author. All other rights reserved by the author.

Version Control: Why It Matters in Software Development

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.

Code Reviews: Writing Better Software Through Collaboration and Feedback

Hello everyone, and welcome to my third blog entry of the semester!

For this week’s self-directed professional development, I read the article “Best Practices for Peer Code Review” from SmartBear Software (smartbear.com). This article provides practical guidelines and research-backed insights on how to conduct effective code reviews in a professional setting. Reading it gave me a new appreciation for how structured review processes can transform not only the quality of code but also team communication and learning.

Summary of the Article

The article begins by explaining that code review is one of the most powerful tools for improving software quality. It cites studies showing that even small, well-structured reviews can significantly reduce bugs and improve maintainability.

Some key practices stood out to me:

  • Keep reviews small: Review no more than 400 lines of code at a time.
  • Limit review sessions: Spend no more than 60 minutes per review to stay focused.
  • Encourage collaboration: Authors should add comments and explanations to help reviewers understand their changes.
  • Focus on learning, not blame: Code review is most effective when it fosters shared ownership and continuous improvement.

The article also introduces metrics like inspection rate and defect rate, which can be used to measure how effective a review process is. Overall, the main message is that a good review culture combines process discipline with respect, clarity, and open communication.

Why I Selected This Resource

I chose this article because it connects directly to my real-world experience at The Hanover Insurance Group, where I worked as a PL Automation Developer intern. During my time there, code reviews were a core part of our workflow. Every piece of automation code had to go through review before deployment. I noticed that following consistent guidelines, like those mentioned in the SmartBear article, made a huge difference in maintaining quality and avoiding errors.

Since we’ve been focusing on software design and collaboration in class, this article helped me bridge what I’ve learned in theory with what professionals practice daily.

Personal Reflections: What I Learned and Connections to Class

Reading this article helped me connect classroom concepts like clean design, modularity, and readability with the real-world practice of peer review. At Hanover, I experienced firsthand how detailed feedback from senior developers helped me understand why small changes, like naming conventions or modularizing functions, mattered in the long run.

This article reminded me that code review isn’t just about technical correctness, it’s also about communication. Explaining your decisions helps others understand your design thinking, just like how UML diagrams or documentation clarify structure in class projects.

Application to Future Practice

Going forward, I plan to adopt SmartBear’s recommendations in both academic and professional work. I’ll keep my commits small, make my code clear and documented before review, and always focus on learning from feedback rather than defending my work. I’ve learned that humility and collaboration are just as essential to great software as technical skill.

Citation / Link
SmartBear Software. “Best Practices for Peer Code Review.” SmartBear, 2024. Available online: https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/

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.

Understanding Design Patterns: Creational, Structural, and Behavioral

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.

Development Environment

Development Environments in Software Process ManagementDownload

From the blog CS@Worcester – dipeshbhattaprofile by Dipesh Bhatta and used with permission of the author. All other rights reserved by the author.

Bridging Structure and Flexibility: Understanding Software Design Methodologies and Agile

Hello everyone, and welcome to my blog entry for this week!For this week’s self-directed professional development, I explored the topic of Software Design Methodologies and Agile Practices. I used several online resources, including tutorials from Atlassian Agile Coach and readings from GeeksforGeeks. Even though the focus was on understanding Agile methodologies, I found that many of the ideas connected directly to our discussions in class about the software development life cycle (SDLC) and software design principles.

Summary of the Resource

Software design methodologies provide structured approaches to building and maintaining software systems. They define how development teams plan, design, implement, test, and deliver software. Traditional methodologies like the Waterfall Model, V-Model, and Spiral Model follow a sequential or plan-driven approach — where each stage must be completed before the next begins. These models emphasize documentation, predictability, and control.

On the other hand, Agile methodologies such as Scrum, Kanban, and Extreme Programming (XP) prioritize adaptability, collaboration, and continuous feedback. Agile breaks development into small iterations or “sprints,” allowing teams to quickly adjust to changes in requirements or user needs. Instead of rigidly following a plan, Agile embraces flexibility — delivering functional software early and improving it continuously.

The Agile Manifesto summarizes this philosophy in four values:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Why I Selected This Resource

I chose to focus on Agile methodologies because I wanted to understand how modern development teams manage complexity in real-world projects. We often hear about Agile in professional settings, but I wanted to explore why it has become so widely adopted. After learning about structured models like Waterfall, I was curious to see how Agile differs in terms of flexibility, teamwork, and iterative design.

This topic also connects closely to our class discussions on object-oriented design and project management, where adaptability and maintainability are key. Understanding these methodologies helps bridge the gap between theoretical design principles and practical implementation in team environments.

Personal Reflections: What I Learned and Connections to Class

Exploring Agile helped me see how methodology shapes not only the process but also the culture of software development. Here are a few takeaways that stood out to me:

  • Iteration mirrors refinement in design. Just like UML diagrams evolve as designs improve, Agile projects evolve through sprint cycles that incorporate feedback.
  • Communication is central. In Agile, daily stand-ups and retrospectives ensure the entire team stays aligned, similar to how collaboration in object-oriented design ensures consistent architecture.
  • Adaptability is a strength, not a weakness. While traditional models aim for stability, Agile embraces change — which is essential when building modern, user-driven applications.

In class, we often focus on designing systems that can evolve. Agile reinforces that same mindset at the project management level software design should anticipate growth, not resist it.

Application to Future Practice

Moving forward, I plan to apply Agile thinking to my future software projects, especially in group work or larger systems. Instead of trying to perfect a design from the start, I’ll focus on building incrementally, testing continuously, and welcoming feedback early in the process.

For example, in future programming projects, I could organize development into short milestones, use version control branches to represent sprints, and hold mini “retrospectives” after each stage. These habits will not only improve collaboration but also help me develop adaptable, high-quality code.

Citation / Link

Atlassian Agile Coach. “What is Agile?” Atlassian. Accessed October 2025. https://www.atlassian.com/agile
GeeksforGeeks. “Software Development Life Cycle (SDLC) and its Models.” 2025. https://www.geeksforgeeks.org

This exploration helped me connect the structured approaches of traditional methodologies with the flexibility and innovation of Agile. It reinforced that software design isn’t just about code — it’s about creating systems and processes that can evolve as technology and user needs change.

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

From UML to Design Patterns: Refactoring the Duck Simulator

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.

Blog 1 Version Control

 Version Control in Software Process Management 

I am Dipesh Bhatta, and I am writing this blog entry for CS-348 Software Process Management for Blog Quarter 1. I chose to write about version control and how it is applied in software process management. My chosen resource is an article entitled “What is Version Control?” by Atlassian’s Git tutorials ( https://www.atlassian.com/git/tutorials/what-is-version-control ). This passage explains what version control is, why software projects require it, and how developers use it in practice. 

The passage defines version control as a process that records file changes over time. It allows several people to work on the same project simultaneously without losing work or overwriting each other’s work. Another important advantage is that version control has a complete history of the project, and developers can go back to an earlier version or reverse mistakes when necessary. The article also explains how the older systems, like the centralized ones such as Subversion (SVN), differ from newer distributed systems such as Git. Git has risen to be the most widely used version control system because it offers each developer a full copy of the project; thus, it is reliable and flexible. Apart from this, the article captures the workflows like branching, merging, and pull requests, which make collaboration safer and more structured. 

I used this resource because version control is associated with managing the software process, the subject of CS-348. The course is all about managing software development in an organized fashion, and version control is one of the most important tools used to facilitate this process. I also wanted to understand the reason why version control is crucial and not just how to use it, since understanding its purpose makes me aware of its application in professional software development. 

This article made me realize version control is not just saving code—it is a process of keeping collaboration and advancement. Without it, projects quickly become unmanageable, and you can’t even know who did what to the code. The explanation of Git branches was most helpful because it mirrors what we do in CS-348. Branches allow developers to experiment with new functionality without affecting the original codebase, and this is a clear demonstration of process management in action. 

The article also got me to think about my own working habits. Writing good commitment messages, responsible use of branches, and adherence to a process-based workflow are all habits that enhance collaboration and project quality. These habits will benefit me in group projects from now on and later in professional work. 

In short, version control is an essential part of software process management. It facilitates collaboration, organization, and accountability—all major themes in CS-348. By performing these routines throughout Blog Quarter 1, I am creating technical skills as well as professional routines that will benefit me throughout my career. 

From the blog CS@Worcester – dipeshbhattaprofile by Dipesh Bhatta and used with permission of the author. All other rights reserved by the author.

Connecting Object-Oriented Principles to UML Class Diagrams

Hello everyone, and welcome to my first blog entry of the semester!

For this week’s self-directed professional development, I listened to the podcast

SOLID Principles with Uncle Bob (Robert C. Martin) on Hanselminutes. (hanselminutes.com) Even though the focus of the episode was on SOLID design principles, I found that many of the ideas connected back to the object-oriented design principles we covered in CS-343 last week. The principles were inheritance, polymorphism, encapsulation, and abstraction, and also tied naturally into our current topic of UML class diagrams.

Summary of the Podcast

Here I am just going to give you guys a tiny summary of the podcast. It’s about 45 mins.

In this episode, Scott Hanselman interviews Robert C. Martin, known as “Uncle Bob,” about how object-oriented design principles shape the flexibility and maintainability of software. He explains why well-structured code allows systems to grow and adapt, while poor design leads to fragile, hard-to-maintain projects. Uncle Bob also emphasizes the importance of thinking carefully about class responsibilities and relationships early in the design phase, which is exactly what UML class diagrams are meant to capture.

Why I Selected This Resource

I chose this podcast because it offered a professional perspective on how design principles go beyond theory and impact real-world software. Since we just studied the four pillars of OOP and are now practicing UML diagrams, I wanted a resource that would help me bridge those two areas. The episode did exactly that: it showed how principles like abstraction or encapsulation are not just coding rules but also influence how we design and visualize systems.

Personal Reflections: What I Learned and Connections to Class

Listening to Uncle Bob made me reflect on how the four OOP principles are deeply connected to UML diagrams:

  • Encapsulation: In diagrams, private attributes and public methods show how data is protected yet accessible through controlled interfaces.
  • Inheritance: The “is-a” relationships in UML are not just arrows; they communicate how subclasses extend parent classes without duplicating logic.
  • Polymorphism: Method overriding and dynamic behavior become clearer when you see how subclasses can stand in for parents in a diagram.
  • Abstraction: Interfaces and abstract classes in UML help highlight shared behaviors without tying designs to specific implementations.

What stood out to me was how Uncle Bob framed design decisions as long-term investments. A UML diagram isn’t just a class picture, it’s the foundation for whether the software remains adaptable or becomes rigid.

Application to Future Practice

Going forward in CS-343, I’ll use these insights to strengthen my UML class diagrams. I plan to treat encapsulation, inheritance, polymorphism, and abstraction as a checklist when building diagrams. For example, when defining relationships, I’ll ask whether inheritance truly makes sense or if abstraction through an interface is better. These habits will not only help me in this course but also in future projects where design clarity and flexibility are essential.

Citation / Link

  • Hanselman, Scott. SOLID Principles with Uncle Bob – Robert C. Martin. Hanselminutes Podcast, Episode #145, January 5, 2009. Available online. (hanselminutes.com)

This resource helped me connect the four pillars of object-oriented programming we studied last week with the UML class diagrams we are now practicing. It reinforced that principles and diagrams go hand in hand, shaping how professional software is designed and maintained.

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