Category Archives: Week 1

Strategic Web Systems Implementation: Key Principles for Modern Applications

For this week’s professional development blog, I delved into the article “Modern Web Implementation: Best Practices & Strategies” from NoPassiveIncome. The piece provides an actionable, business-oriented framework for building web systems that are performant, maintainable, and user-centric. Given our course focus on web architecture, design, and deployment, this article offers vital insights that closely align with our syllabus.

Summary of the Article

The article begins by establishing the importance of robust web implementation, arguing that effective execution translates design into a reliable, high-performance website. It underscores that a poorly implemented system can degrade user experience, SEO, and long-term maintainability.

Key elements of strong web implementation are described in detail:

  • User Experience (UX): The article emphasizes intuitive navigation, clean design, and accessibility, asserting that a stellar UX fosters engagement and retention.
  • Responsive Design: Given the ubiquity of mobile devices, implementation should prioritize fluid layouts that perform seamlessly across a range of screen sizes.
  • SEO Best Practices: From keyword placement to meta tags, the article recommends embedding SEO considerations into the implementation phase rather than treating them as an afterthought.
  • Performance Optimization: Techniques such as image compression, code minification, and browser caching are explored to minimize load times and maximize responsiveness.

The article also addresses common challenges, such as cross-browser compatibility and mobile optimization and offers practical solutions like extensive testing and responsive design. It highlights emerging trends in web implementation, including progressive web apps (PWAs), voice search optimization, and AI-powered chatbots. Finally, the piece recommends essential tools like Google Analytics for behavior tracking, SEMrush for SEO analysis, and Bootstrap for streamlined responsive development.

Why I Chose This Resource

I selected this article because it directly aligns with our Implementation of Web Systems course. We’ve been discussing architecture, design trade-offs, and the practicalities of building real-world web applications. This resource synthesizes those academic topics into concrete, industry-ready guidelines.

Moreover, as I prepare for future roles where I may design, maintain, or deploy web systems, I want a strategic understanding of implementation that goes beyond coding, one that balances technical best practices with user-centered concerns.

What I Learned & How It Enhances My Understanding

This article reinforced for me that web implementation is more than just writing code, it’s about strategic execution. The discussion of UX taught me that simplicity and accessibility matter just as much as backend logic. When I build web systems in class, I plan to pay greater attention to how every design decision affects usability.

I was also struck by the emphasis on SEO during implementation. In class, SEO sometimes feels secondary, but this article made clear how deeply it should influence how we build, structure, and implement web pages.

Finally, the performance optimization section resonated strongly with what we’ve learned about efficient web architecture. Minimizing asset size and leveraging browser caching are practical techniques that I aim to use in future projects to ensure speed and reliability.

How I Will Apply These Insights

In upcoming web development assignments and real-world projects, I plan to:

  • Start with user experience design and accessibility, not just backend features.
  • Build always with responsive layouts and test across devices.
  • Treat SEO as an integrated component of implementation, not an afterthought.
  • Implement performance optimizations from the beginning, including image compression, code minification, and caching.
  • Use analytics tools like Google Analytics to track performance and gather actionable user behavior data.

This article has deepened my confidence in building web systems that are not only functional, but also optimized, user-friendly, and future-proof, exactly the kind of approach this course encourages.

Citation / Link
“Modern Web Implementation: Best Practices & Strategies.” NoPassiveIncome, accessed 2025. Available online: https://nopassiveincome.com/modern-web-implementation/

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

Professional Insights on Software Maintenance

Hello everyone, and welcome to my latest and most likely my last blog entry of the semester!

For this week’s self-directed professional development, I read “The Ultimate Software Maintenance Guide” from Mayura Consultancy Services. This article offers a thorough, business‑oriented perspective on software maintenance, covering everything from types of maintenance to common challenges, processes, and best practices. It helped me prepare mentally and technically for the maintenance project I’m about to begin at The Hanover Insurance.

Summary of the Article

The Mayura Consultancy guide begins by defining software maintenance as a continuous process of modifying and updating software to correct defects, improve performance, and adapt to changing business needs.

It breaks down four main types of maintenance:

  1. Preventive maintenance – proactively identifying and resolving potential issues before they escalate.
  2. Corrective maintenance – fixing bugs and defects reported in production.
  3. Adaptive maintenance – adjusting the software to work with new operating systems, regulations, or business requirements.
  4. Perfective maintenance – enhancing performance or usability, or adding new features.

The article also outlines the key challenges maintenance teams face: dealing with legacy code, managing complexity, controlling costs, and allocating time. It spells out a maintenance process that includes issue identification, evaluation, planning, implementation, testing, and deployment.

Mayura then describes four maintenance models—like the Quick-Fix Model, Iterative Enhancement, Reuse-Oriented, and Boehm’s Model—each suited for different business contexts. The article finally offers best practices, which include maintaining documentation, collecting and analyzing data, performing regular testing, monitoring performance, and sharing knowledge within the team. They close by discussing the benefits of maintenance: extended software lifespan, better security, cost savings, and increased user satisfaction.

Why I Chose This Resource

I selected this article because I’m about to begin my first maintenance project at The Hanover Insurance Group. Knowing effective maintenance practices will be crucial as I work on updating and sustaining existing software. This piece from Mayura Consultancy provides both a high-level strategic vision and practical, actionable steps — exactly what I need for a professional maintenance context.

Also, in my software engineering classes, we emphasize design, clean code, and testing. This article helped me see how those principles carry over into maintenance: not just writing code once, but caring for it over time.

Personal Reflections: What I Learned and How It Connects to Class

This article emphasized to me that software maintenance is not just reactive — it’s a proactive, vital phase in the software lifecycle. From class, I understood design patterns and modular structures, but Mayura’s guide made me realize that those good design decisions pay dividends later, when maintenance is needed.

The breakdown of different maintenance types (preventive, adaptive, etc.) was especially eye-opening. It taught me to think about maintenance not only as bug-fixing but also as a strategic activity that aligns with business change.

I was particularly struck by how essential good documentation is. In class, we talk about commenting code and writing clear functions — but in maintenance, that clarity supports future developers and reduces downtime.

Application to My Future Practice

In my maintenance work, I plan to:

  • Use Mayura’s structured maintenance process (identification → planning → implementation → testing → deployment) whenever I handle a bug or feature update.
  • Prioritize preventive maintenance so I’m not always on the back foot.
  • Keep documentation up to date — not just in code, but in architecture, logs, and change-tracking.
  • Advocate for regular testing cycles (unit, regression) and performance monitoring.
  • Share my learnings with teammates, so we maintain a shared, growing knowledge base.

Citation / Link
Rao, Ashwin Kumar. “The Ultimate Software Maintenance Guide: Tips, Tricks, and Best Practices.” Mayura Consultancy Services, updated November 1, 2025. Available online: https://www.mayuraconsultancy.com/blog/ultimate-guide-to-software-maintenance

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.

Learning How Architecture Patterns Shape Reliable Software

For my first blog, I read “Software Architecture Patterns” from the ByteByteGo blog. The post explains what architecture patterns are, why they exist, and how they help developers organize software systems that scale and remain maintainable. It outlines several common patterns such as layered, event-driven, microservices, client server, and micro kernel, describing their main structures and the problems they solve. The article emphasizes that architecture is not about strict rules but about creating a structure that supports clarity, reliability, and growth.

The author shows how the layered pattern divides applications into presentation, business, and data layers, useful for simple or monolithic systems. Event driven architectures handle asynchronous communication, making them ideal for systems that must respond quickly to different events. Microservices split large systems into smaller, independent services that can be developed, deployed, and scaled separately. Client server architecture remains a foundation for most web applications, while micro kernel focuses on extensibility, often used in plugins or modular software.

I chose this blog because it connects directly with what we are learning in CS-343 about design principles, maintainability, and system organization. It presents architecture patterns as practical solutions rather than abstract theories. The visuals and examples in the article made complex ideas clear. Reading it helped me understand that the architecture pattern chosen for a project directly affects performance, scalability, and how teams collaborate.

What stood out to me is the focus on trade offs. Each pattern has strengths and weaknesses depending on the project’s goals. For instance, microservices improve flexibility but increase deployment complexity. Layered systems are easier to start with but can slow down change if dependencies grow too tightly coupled. This reinforced the importance of balancing simplicity, independence, and maintainability, key themes from our class discussions about SOLID and GRASP principles.

From this reading, I learned that good architecture is about creating boundaries that protect core business logic while allowing technology and frameworks to evolve. I plan to apply this by practicing modular design in future projects and thinking more critically before deciding on an architecture. Understanding patterns like microservices or event-driven systems will help me reason about trade offs when I design APIs or backend structures.

Overall, ByteByteGo’s article strengthened my understanding of architecture as the backbone of sustainable software. It made clear that design patterns are not only about writing code but about shaping how software grows over time.

Link: https://www.thoughtworks.com/en-us/insights/blog/architecture/demystify-software-architecture-patterns

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

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.

Introduction(CS-343)

Hi, my name is Jamaal, been a while since i made a blog but coming back to it and getting in the grove of things especially for CS-343, hopefully this will be an enjoyable semester when it comes to learning about software construction/design and architecture .

From the blog CS@Worcester – CSTips by Jamaal Gedeon and used with permission of the author. All other rights reserved by the author.

LeadingAgile SoundNotes: an Agile Podcast

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

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

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

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

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

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

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

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

WEEK 1 | Employing Agile Methodology In Scrum Master Role.

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

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

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

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

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

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

What is Technical Debt

The Future you Problem

Photo by cottonbro studio on Pexels.com

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

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

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

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

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

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

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

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

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

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

Week 1: Object-Oriented Design Principles

Sunday, September 15, 2024

This week I was introduced to Object-Oriented Design Principles. In this week’s blog, I will be discussing what object-oriented design principles are and how these principles help with creating software so that it is easy to maintain.

The Medium blog post by Ravi Patel “Understanding Object-Oriented Design Principles” offers an overview of major object-oriented design principles and how they help to the creation of successful and maintainable software. Object-Oriented Design (OOD) is a software design methodology that views the program as a collection of interacting objects, each representing an instance of a class. Ravi goes on to discuss the fundamental principles, encapsulation, abstraction, inheritance, and polymorphism.

Encapsulation is the process of grouping data and methods that operate on it into a single unit or class while restricting access to certain of the object’s components. This aids in concealing the internal state and requires all interactions to be conducted through an object’s methods.

Abstraction is the process of simplifying complicated systems by modeling classes based on key traits and behaviors, while obscuring unneeded information. This focuses on an object’s actions rather than its methods.

Inheritance allows a new class to inherit characteristics and methods from an existing class, enabling code reuse and establishing a hierarchical connection between classes.

Polymorphism allows objects to be viewed as instances of their parent class rather than their own. This enables the use of a single interface for a broad range of activities, increasing code flexibility and extensibility.

I chose this blog post because it helped me understand the principles better. After this week’s reading I now understand that object oriented principles is a theory that helps developers in how to think about and build code that is easier to work with, simpler to understand, and requires less maintenance overall. When working on my POGIL activity with my team this week, there was a question that asked us to define the principles without looking them up. We defined the principles as follows:

Abstraction is simplifying code
Encapsulation is adding code to already existing code
Polymorphism is many forms of code/methods
Inheritance are classes and their super classes and constructors

Our definitions were not entirely wrong. We could gather what each principle meant to an extent. I see myself applying these principles in my future projects. It would help create readable code that can also be modified easily as needed. This week’s material made me understand that not all long code is helpful. The simpler the code is the better it is for the next developer to read it. When I usually code, I add a lot of unnecessary code that does not need to be there. I hope to improve my code writing skills as I learn more.

Blog link: https://medium.com/@ravipatel.it/understanding-object-oriented-design-principles-0c1e48207c89  

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