Author Archives: Zachary Kimball

Blog & Podcast Discovery – Software Architecture

Resource Selected:
“Patterns of Legacy Displacement” by Ian Cartwright, Rob Horn, and James Lewis
Published on Martin Fowler’s Software Architecture site
https://martinfowler.com/architecture/

Summary of the Resource

This article explores the practical challenges of replacing legacy systems in large-scale organizations. The authors introduce the concept of the “legacy replacement treadmill,” a cycle in which enterprises launch extensive modernization efforts that often stall or fail before meaningful progress is made. The authors argue that the core issues extend beyond outdated technology to include organizational and leadership shortcomings. To address these challenges, they recommend setting clear goals, delivering improvements in small, manageable increments, and avoiding “big-bang” system rewrites which typically lead to failure. Instead, they propose a more sustainable approach: gradually isolating and updating parts of the legacy system, delivering functional components, and slowly retiring the outdated codebase.

Why I Chose This Resource

I selected this article because it directly relates to key principles we’ve discussed in our software design and architecture course, such as maintainability, technical debt, and scalable architecture. Rather than just presenting theory, the article demonstrates real-world consequences when these principles are overlooked. Additionally, I’ve observed similar patterns on a smaller scale during team projects, where the instinct to start from scratch often feels easier than improving existing code. This resource provides a practical, realistic alternative to that approach.

Reflection and Key Takeaways

The most impactful lesson for me is that modernization should not be seen as a rapid technical overhaul but as a long-term, structured effort. The authors emphasize defining clear outcomes before writing any code a concept that shifted my perspective. In future projects, I aim to prioritize measurable objectives over vague goals like “make it better.”

Another important insight is the risk of pursuing feature parity with legacy systems. Attempting to replicate every existing feature can hinder innovation and slow down progress.

The article also deepened my understanding of how human factors such as team habits, organizational power structures, and internal priorities can influence the success or failure of architectural changes. Even the best-designed technical solutions will struggle to succeed without cultural alignment and support for gradual transformation.

Moving forward, I intend to apply this mindset to legacy code by introducing incremental, testable changes that improve the system’s architecture over time. This approach may be slower, but it is ultimately more effective and sustainable.

Link to the Resource:
https://martinfowler.com/architecture/

From the blog Zacharys Computer Science Blog by Zachary Kimball and used with permission of the author. All other rights reserved by the author.

HELLO THIS IS MY CS-343 BLOG

Hello world

From the blog Zacharys Computer Science Blog by Zachary Kimball and used with permission of the author. All other rights reserved by the author.

My Perspective on Risk Based Testing in Software Quality Assurance

As a computer science student getting more into the details of software development, I’ve started to realize how much goes into making sure software actually works the way it’s supposed to. I recently read the article “13 QA Testing Best Practices For 2024” from Testlio, and one part that stood out to me was the idea of risk based testing.
(testlio.com)

Risk based testing is all about using your time and effort wisely. Instead of trying to test every single feature equally, it focuses on the stuff that matters most. You look at what parts of the app are most likely to break or cause problems for users if they fail. Then you make sure those are tested thoroughly before anything else.

The article explains that identifying risky areas early helps teams put their energy in the right place. If you’ve only got so many people and so much time, this method helps avoid wasting those resources. It also means the most important features are solid by the time the app goes live.

This reminded me of a group project I worked on where we made a class management web app. We spent way too much time testing features like color themes and user bios. But when it came to the assignment submission tool, which was probably the most important part, we barely tested it. Sure enough, after we deployed it, users had issues uploading their files. If we had used risk based testing, we probably would’ve caught that.

Now that I know about this approach, I’m going to start using it in future projects. I’ll take time up front to figure out which features are most essential or most likely to go wrong, and make sure we focus testing there first. It’s a simple idea, but it makes a big difference.

In the end, risk based testing is about being smart with your time and making sure what matters most actually works. If you’re also learning software testing, this is a great thing to start thinking about. I definitely recommend checking out the full article if you’re curious:
13 QA Testing Best Practices For 2024

From the blog Zacharys Computer Science Blog by Zachary Kimball and used with permission of the author. All other rights reserved by the author.

A Student’s Perspective on Technical Reviews in Software Quality Assurance

As a computer science student delving into the world of software development, I’ve come to appreciate the significance of various practices that ensure the delivery of high-quality software. One such practice that recently caught my attention is the concept of technical reviews in software quality assurance.​

I explored the article “What is Technical Review in Software Testing?” by Testsigma, which provided a comprehensive overview of this critical process. A technical review is a structured evaluation conducted by a team of peers to assess the technical aspects of software artifacts, such as design documents, code, and test plans. The primary goal is to identify defects and areas for improvement early in the development lifecycle, thereby reducing the cost and effort associated with fixing issues later on.​

The article outlines several key objectives of technical reviews:​

  • Defect Detection: Identifying errors in function, logic, or implementation before they propagate further into the development process
  • Standards Compliance: Ensuring that the software adheres to organizational and industry standards.​
  • Knowledge Sharing: Facilitating the exchange of ideas and knowledge among team members, which can lead to better design decisions and coding practices.​
  • Process Improvement: Providing feedback that can be used to refine development processes and prevent future issues.​

Reflecting on this, I realize that incorporating technical reviews into our academic projects could be highly beneficial. Often, we focus on completing assignments and meeting deadlines, sometimes overlooking the importance of peer evaluations. By implementing structured reviews, we can catch mistakes early, learn from each other’s perspectives, and produce more robust and reliable code.​

Moreover, understanding the practice of technical reviews prepares us for industry expectations, where such evaluations are integral to the development process. It emphasizes the collaborative nature of software engineering and the collective responsibility of a team to ensure quality.​

In conclusion, technical reviews are a vital component of software quality assurance, offering numerous benefits that extend beyond mere defect detection. As students aspiring to become proficient software engineers, embracing this practice can enhance our learning experience and better equip us for professional challenges ahead.​

For a more in-depth understanding, I recommend reading the full article: What is Technical Review in Software Testing?

From the blog Zacharys Computer Science Blog by Zachary Kimball and used with permission of the author. All other rights reserved by the author.

Learning the Ropes: A Student’s Dive into QA Testing Best Practices

I recently came across the article “Best Practices for Software Quality Assurance Testing” by KMS Technology. As a computer science student eager to understand the practical aspects of software development, this piece offered a clear roadmap of the QA process, breaking it down into four main stages: planning, test design, execution, and reporting.

1. Planning: The article emphasizes the importance of early-stage planning, including resource allocation, timeline estimation, and tool selection. This stage sets the foundation for the entire QA process.​

2. Test Design: Here, the focus is on defining both functional and non-functional requirements. The article suggests determining which tests can be automated and which require manual intervention, ensuring comprehensive coverage of user scenarios.​KMS Technology

3. Test Execution: This phase involves running the designed tests and evaluating any defects or issues that arise. It’s a repetitive process, ensuring that each identified problem is addressed and retested.​

4. Reporting and Maintenance: The final stage is about documenting findings, analyzing results, and ensuring that the software is ready for release. Continuous feedback loops between testers and developers are crucial here.​

Reflecting on these stages, I realize how often, in academic projects, we might overlook structured testing due to time constraints or lack of emphasis. However, this article highlights that integrating testing throughout the development cycle, rather than treating it as a final step, leads to more reliable and efficient software.

One key takeaway for me is the significance of clear communication and documentation. In group projects, miscommunication can lead to redundant work or overlooked bugs. By adopting a structured QA approach, we can mitigate these issues.

In conclusion, this article has provided me with a practical framework for approaching software testing. As I continue my studies and work on more complex projects, I plan to implement these best practices to enhance the quality and reliability of my work.

For those interested in a deeper dive, here’s the full article: Best Practices for Software Quality Assurance Testing.

From the blog Zacharys Computer Science Blog by Zachary Kimball and used with permission of the author. All other rights reserved by the author.

What I Learned About QA: A Computer Science Student’s Take on Real-World Testing Practices

I recently read the article “Streamlining the QA Process: Best Practices for Software Quality Assurance Testing” published by KMS Technology. As a college student studying computer science and still learning the ins and outs of software testing, I found this article especially helpful. It gave me a clearer understanding of what quality assurance (QA) really looks like in real-world software projects.

I chose this article because I’ve been trying to get a better grasp on how testing fits into the bigger picture of software development. A lot of what we learn in class focuses on writing code, but not always on making sure that code actually works the way it’s supposed to. This article breaks down what can go wrong in the testing process and how to avoid those issues, which is something I know I’ll need as I continue learning and working on team projects.

The article talks about a few key challenges that QA teams run into:

Unclear Requirements – This one really stood out to me. The article explains that if the project requirements aren’t clearly defined, testing becomes almost impossible. How can you verify if something works if you’re not even sure what it’s supposed to do? It made me realize how important it is to ask questions early on and make sure everyone’s on the same page before writing code.

Lack of Communication – The article also highlights how communication gaps can mess up testing. If developers and testers aren’t talking regularly, bugs can slip through the cracks. As someone who’s worked on class group projects where communication wasn’t great, I totally see how this could happen on a larger scale.

Skipping or Rushing Testing – The article warns against rushing through testing or treating it like an afterthought. I’ve definitely been guilty of this in my own assignments—leaving testing until the last minute, which usually results in missing bugs. The article suggests integrating testing throughout development, not just at the end, and that’s something I want to start practicing more.

Reading this article made me reflect on my own experience so far. In one of my programming classes, our final project had a vague prompt and my group didn’t ask enough questions. We ended up spending extra time rewriting parts of our code because the requirements kept changing. After reading this article, I see how important it is to define everything early and communicate often.

I also plan to be more intentional about testing as I continue to build projects. Instead of waiting until the code is “done,” I want to get into the habit of testing as I go and making sure I understand the expected behavior before writing a single line.

Overall, this article helped me understand why QA is such a critical part of software development—not just something to tack on at the end. If you’re also a student learning about testing, I recommend giving it a read: Streamlining the QA Process: Best Practices for Software Quality Assurance Testing.

From the blog CS@Worcester – Zacharys Computer Science Blog by Zachary Kimball and used with permission of the author. All other rights reserved by the author.

Kicking off the Blog

Hello fellow CS pursuers! I’m Zachary Kimball and this is my blog started for my CS-443 course.

I’m pretty sure I messed up tagging or something about my last post so I created a new domain and hopefully this go around is better!

This blog is mainly focused around my CS class I’m enrolled in with professor Perez at the moment but I hope to continue it in the future!

From the blog CS@Worcester – Zacharys Computer Science Blog by Zachary Kimball and used with permission of the author. All other rights reserved by the author.

Management Pitfalls, How to Navigate Them

I recently read the article “Common SDLC Management Pitfalls (And How To Avoid Them)” published on Forbes.com. This insightful piece delves into prevalent challenges encountered during the Software Development Life Cycle (SDLC) and offers practical strategies to mitigate them.

I selected this article because, as someone striving to enhance my understanding of software process management, recognizing common pitfalls is crucial for effective project execution. The article’s focus on real-world issues and solutions provides valuable guidance for both current and future projects.

The article identifies several key pitfalls in SDLC management:

  • Unclear Requirements: It emphasizes that ambiguous or incomplete requirements can lead to project delays and cost overruns. The recommendation is to engage stakeholders early and ensure thorough documentation to establish a clear project scope.
  • Inadequate Communication: The piece highlights that poor communication among team members can result in misunderstandings and errors. Implementing regular meetings and utilizing collaborative tools are suggested to enhance information flow.
  • Lack of Proper Testing: The article points out that insufficient testing can cause defects to reach production, affecting product quality. It advocates for integrating comprehensive testing phases within the development process to identify and address issues early.

Reflecting on these insights, I recognize the importance of establishing clear requirements from the outset. In past projects, I’ve experienced setbacks due to vague objectives, leading to scope creep and resource strain. Moving forward, I plan to prioritize stakeholder engagement to define precise and attainable goals.

The emphasis on communication resonates with my experiences in team settings. I’ve observed that regular check-ins and transparent discussions significantly reduce misunderstandings and align team efforts. I intend to advocate for consistent communication channels in future collaborations to maintain project coherence.

The article’s focus on testing underscores a critical aspect of software development. Previously, I underestimated the value of early and thorough testing, which led to last-minute defect discoveries. I now understand that incorporating iterative testing phases can enhance product quality and reduce time-to-market.

In conclusion, this article has deepened my understanding of common SDLC pitfalls and reinforced the necessity of proactive management strategies. By applying these lessons—clarifying requirements, fostering open communication, and committing to rigorous testing—I aim to contribute to more efficient and successful software development projects in the future.

For those interested in exploring this topic further, I recommend reading the full article: Common SDLC Management Pitfalls (And How To Avoid Them).

From the blog CS@Worcester – Zacharys Computer Science Blog by Zachary Kimball and used with permission of the author. All other rights reserved by the author.

Smarter Ways to Gather Software Requirements

I recently read the article “Gathering Requirements for a Development Project in 2025” on Developer-Tech.com. The article talks about how collecting and understanding software requirements is changing, focusing on new technologies and ways of working to make the process better.

I picked this article because I want to improve how I manage software projects. Gathering requirements is such an important part of any project, and understanding future trends can help me stay ahead. The article gave clear examples of how requirement gathering is improving and what to expect in the coming years.

The article covered three key points:

  • Using Artificial Intelligence (AI): It explains how AI tools can make collecting and understanding requirements faster and more accurate. AI can analyze a lot of data quickly and help figure out what stakeholders (the people involved in the project) need.
  • Better Team Collaboration: The article emphasizes how important teamwork is. New communication tools are helping teams work together more easily, making sure everyone understands the project’s goals.
  • Agile Development Methods: It talks about Agile, a way of working that breaks projects into smaller steps. Agile lets teams adjust requirements as they go, so the final product meets user needs better.

This article made me think differently about how I collect and organize project requirements. The idea of using AI tools stood out to me because it would make the process quicker and catch mistakes I might miss. In the past, I’ve done everything manually, and it can take a lot of time.

The part about teamwork also hit home for me. I’ve worked on projects where poor communication caused delays and confusion. Using tools that help everyone stay connected and clear about the goals can make a big difference.

I also liked what the article said about Agile. I’ve worked on projects where requirements changed halfway through, and it was stressful. Agile makes it easier to handle those changes, which is something I plan to learn more about and use in future projects.

Overall, this article was a great introduction to how requirement gathering is improving. By using AI, working more closely with teams, and adopting Agile methods, I can do a better job on projects. If you’re interested, I recommend reading the full article: Gathering Requirements for a Development Project in 2025.

From the blog CS@Worcester – Zacharys Computer Science Blog by Zachary Kimball and used with permission of the author. All other rights reserved by the author.

Good Git Resources to Help Beginners Learn

recently read the article “Git Best Practices – A Guide to Version Control for Beginners” on freeCodeCamp.org. This piece offers a comprehensive introduction to Git, emphasizing essential practices for effective version control.

I chose this article because, as a newcomer to software process management, I wanted to understand how Git can enhance collaboration and efficiency in development projects. The article’s focus on best practices provided a clear roadmap for integrating Git into my workflow.

The content delves into fundamental Git concepts, such as initializing repositories, committing changes, and branching strategies. It underscores the importance of clear commit messages and regular repository maintenance. A key takeaway for me was the significance of atomic commits—ensuring each commit represents a single, logical change. This practice not only simplifies tracking changes but also aids in pinpointing issues during code reviews.

The article also highlights the role of branching in facilitating parallel development. Understanding how to create and manage branches allows for isolated feature development, reducing the risk of conflicts in the main codebase. This insight has reshaped my approach to project structuring, making me more confident in handling complex tasks.

Reflecting on the material, I’ve realized the transformative impact of adhering to Git best practices. They not only streamline the development process but also foster better team collaboration. Moving forward, I plan to implement these practices diligently, aiming to contribute more effectively to projects and enhance overall code quality.

For those interested in exploring this topic further, I recommend reading the full article on freeCodeCamp.org: Git Best Practices – A Guide to Version Control for Beginners.

From the blog CS@Worcester – Zacharys Computer Science Blog by Zachary Kimball and used with permission of the author. All other rights reserved by the author.