Tag Archives: CS@Worcester

CS343-01: Week (Quarter) Two

Software Constr – Blog Two

In class, we learned two acronyms. DRY which was Don’t Repeat Yourself and YAGNI which meant You Ain’t Gonna Need It. So, I was curious as to what others we had and why we had them in the first place.

When researching on why acronyms like DRY and YAGNI are important, I came across that “in the ever-evolving world of software development, clean, maintainable code isn’t a luxury — it’s a survival skill. As systems grow and teams scale, codebases can quickly become tangled, brittle, and expensive to change.” The acronyms are principles that help us write code that are sustainable and that even though they’re easy to understand, they’re powerful when applied.

Alongside DRY and YAGNI, there’s also KISS (Keep It Simple, Stupid). The KISS principle “encourages developers to avoid unnecessary complexity. Whether you’re writing a function or designing an entire system, simplicity is often the best strategy.” This is important since if there’s a lot involved in the project, then there’s a lot more risk of bugs when can result in the needless complexity, rigidity, etc. that we learned in class.

This principle was actually created by a systems engineer named Kelly Johnson who was working for Lockheed Skunk Works which was the team that developed the SR-71 Blackbird (“a retired long-range, high-altitude, Mach 3+ strategic reconnaissance aircraft,” according to Wikipedia). “His idea was simple: systems should be so straightforward that even someone with basic training could repair them under stressful conditions — like in combat. This philosophy translated beautifully into software, where complexity is often the enemy of reliability.”

I learned that DRY “was introduced by Andy Hunt and Dave Thomas in their 1999 book The Pragmatic Programmer. Their definition was concise but profound: ‘Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.’” It helps reduce redundancy and speed up development in a project.

I learned that YAGNI worked as “a reminder to avoid building features or abstractions that aren’t immediately required” because of the encouragement it gives to “developers to resist the urge to ‘future-proof’ code based on assumptions about needs that may never materialize.” I also learned that YAGNI came from a thing called Extreme Programming (XP) and was popularized by Ron Jeffries, one of the original Agile Manifesto signatories. It became a core tenet of XP: ‘Always implement things when you actually need them, never when you just foresee that you need them.’” It helped prevent overthinking in engineering and keep the development focused on solving the problems of today rather than in the future.

Source: https://levelup.gitconnected.com/software-architecture-explaining-kiss-dry-yagni-with-practical-examples-in-typescript-9bf23c484816 

From the blog CS@Worcester – The Progress of Allana R by Allana Richardson and used with permission of the author. All other rights reserved by the author.

More Information on Agile and Scrum

I decided to write this self-directed blog entry on an article I found regarding information and differences between Agile and Scrum, two topics we have recently been covering in class. I sought to learn more about these two topics, as I was not entirely confident in my understanding of them. I unfortunately was absent due to an illness on the day we covered the Agile methodology in class, so in order to get a better understanding on the topic, I went through the activity and learned more about it on my own time. This article summarizes what Agile and Scrum are, their differences, the core Agile values and principles, the basics of Scrum, and when and how they should be utilized. This was quite a thorough read and was very informative to reinforce what I had learned from the class. One thing that I did not immediately connect from class was that Scrum was based on the Agile philosophies. As best said in the article, Agile is the guiding principles to shape how you work, Scrum gives a structured playbook to follow.

Though I do not plan to go into software development as a career path, I think this is still a beneficial way to learn quality teamwork and collaboration. Regardless of concentration or field of study, computer science and information systems related disciplines require efficient teamwork and collaboration. Working professionally in the field for four years now, there has never been a project or major task that involved no one besides myself. I always had to work with different teams to accomplish the final goal that was needed. Learning this framework could be very beneficial for me moving forward so I can apply it to my future professional projects. Having better tools almost always leads to a better job done, and I always strive to improve and better myself as a technology professional.

One discovery made from this article is that there are other common implementations of Agile outside of Scrum. One of these, I recognized from my professional experience, as my current organization requires all full-time staff to participate in Lean training. I was not aware that Lean training, which according to the article, “aims to eliminate waste and maximize customer value by focusing on efficiency and continuous improvement,” was an extension of the Agile methodology. This is critical, especially in the healthcare environment that I work in. It is an everchanging field and an environment that can change drastically within a matter of seconds. Though I am not a full-time employee and have yet to participate in that training, I will participate in it once I resume full-time work permanently at the end of December 2025.

ZG

The link to the blog post: https://monday.com/blog/rnd/agile-vs-scrum/

From the blog CS@Worcester – zach goddard by Zach Goddard and used with permission of the author. All other rights reserved by the author.

Principle of Least Knowledge (AKA Law of Demeter)

Hello everyone, today I will be talking about the Principle of Least Knowledge (AKA Law of Demeter). When first looking into this topic I was unsure of exactly what this was and how it would be applied to programming. When doing my research I found the Khouri College of Computer Sciences at North Eastern University had a page dedicated to this topic, where this law was first introduced.

General Formulation

Illustration of the Law of Demeter, highlighting the principle of limiting interactions between objects.

The LoD is essentially a simple style rule for designing object oriented systems.

“Only talk to your immediate friends” is the motto. 

Professor Leiberherr, the author, states a formulation of “Each unit should have only limited knowledge about other units: only units “closely” related to the current unit.Its main motivation is to control information overload thus helping memory management as each item is closely related.

You can informally summarize the Law with these three formulations:

  • Each method can only send messages to a limited set of objects, namely to the argument objects and to the immediate subparts of the class to which the method is attached.
  • Each method is “dependent” on a limited set of objects (organize dependencies)
  • Each method “collaborates” with a limited set of objects (organize collaborations)

To formulate the Law we can choose from the following independent possibilities:

  • Object/Class
    • Class formulation is intended to be compile-time
    • Object formulation is intended to be followed conceptually
  • Messages/Generic functions/Methods
  • Weak/Strong
    • If we interpret it as all instance variables, including the inherited ones, we get the weak form of the Law. If we exclude the inherited instance variables, we get the strong form of the Law.

Benefits

In a paper written by Leiberherr, there are a couple facts stated for the benefits:

  • If the weak or strong LoD is followed and if class A’s protocol is renamed, then at most the preferred client methods of A and A’s subclasses require modification.
  • If the weak or strong LoD is followed and if the protocol of class A changes, then only preferred client methods of A and its subclasses need to be modified and only methods in the set of potential preferred clients of A and its subclasses need to be added
  • There’s even more benefits highlighted in the paper pertaining to limiting information overload.

Final Thoughts:

Prior to this webpage I knew nothing about this law/principle, however I now understand that it is a fairly useful rule or its respective use case. The law teaches you a way to program Classes, Inheritance, Abstraction, and a few other techniques. Infact There is so much more depth to this that I cant even fully fit it into this blog post. I would highly recommend you check out this page as It contains all the information you need along with sources to learn this.

From the blog Petraq Mele blog posts by Petraq Mele and used with permission of the author. All other rights reserved by the author.

How to become a SOLID software developer.

By Petraq Mele

Hello again to those reading this blog, this time I want to talk about an extremely topic relevant in the programming atmosphere, that being a concept known as SOLID. I managed to find a great section written by Manoj Phandis on these principles.

SOLID is an acronym of five OOP design principles designed to help make it more understandable, flexible, and maintainable.

What are the main 5 design principles?

SINGLE RESPONSIBILITY PRINCIPLE: This principle states a class should have one, and only one, reason to change. Lets take an Animal class example, as opposed to the animal class having a sound and feed parameter, separate those responsibilities into separate classes.

Some benefits include:

  • more readable, that is easier to understand
  • less error prone
  • more robust
  • better testable
  • better maintainable and extendable
  • maximizes the cohesion of classes.

OPEN CLOSED PRINCIPLE: “Open for extension” means the behavior of a module can be extended. “Closed for extension” means when we are adding/extending a modules behavior it should not result in changes to a modules source or binary code.

Demonstration of the Open/Closed Principle in object-oriented programming.

An example Manoj gives is a credit card company wanting to introduce a new preferred credit card product with double reward points. Instead of using conditionals, you create an extension via implementation inheritance or interface abstraction.

LISKOV SUBSTITUTION PRINCIPLE: LSP states functions that use references to base classes must be able to use objects of the derived class without knowing it. For LSP compliance we need to follow some rules that can be categorized into 2 groups:

  • Contract rules
    • Preconditions cannot be strengthened or weakened in a subtype
    • Invariants must be maintained
  • Variance rules
    • There must be contra-variance of the method argument in the subtype & be covariance of the return type in the subtype
    • No new exceptions can be thrown by the subtype unless they are part of the existing exception hierarchy.

INTERFACE SEGREGATION PRINCIPLE: Clients should not be forced to depend on methods they do not use. Interface segregation violations result in classes depending on things they don’t need & an increase of coupling and reduced flexibility/maintainability.

Tips to follow:

  • Prefer small, cohesive interfaces to “fat” interfaces
  • Creating smaller interfaces with just what we need
  • Have the fat interface implement your new interface.
  • Dependency of one class to another should depend on the smallest possible interface.

DEPENDENCY INVERSION PRINCIPLE: This principle has two parts. The first part says high-level modules should not depend on low-level modules. Both should depend on abstractions. The second part says Abstractions should not depend on details. Details should depend on abstractions.

Part one example:

Part two example:

Final thoughts:

Overall these principles are very useful when it comes to object-oriented software development. I learned quite a good amount and I want to thank Manoj Phandis for their amazing outline of the SOLID principles, I would advise you to check them out in his website incase you’re interested in learning more.

From the blog Petraq Mele blog posts by Petraq Mele and used with permission of the author. All other rights reserved by the author.

Team management in software development

As a software developer there is a significant chance that you will develop software in a team environment. I know as an entry level developer gaining this experience beforehand would be a massive boost for my career but what exactly does team management entail?

The importance of team management

In a perfect world a team of developers all work perfectly together synchronously & complete a task in the best way possible. In reality, each team will have people of different skillsets, creativity, and ideas for development. Therefore, teams need to be managed in order to optimize development as much as possible.

Diagram illustrating the roles within a software project development team.

Creating a team

Before assembling a team for a project its important to highlight the scope & needs in order to figure out how many, and the type of, developers. According to itrex, some examples of developers you may need would be:

– Software Developer: Engineers and stabilizes the product & solves any technical problems emerging during the development lifecycle
– Software Architect:
Designs a high-level software architecture, selects appropriate tools and platforms to implement the product vision, & sets up code quality standards and performs code reviews
– UI/UX Developer:
Transforms a product vision into user-friendly designs & creates user journeys for the best user experience and highest conversion rates
– QA(quality assurance) Engineer:
Makes sure an application performs according to requirements & spots functional and non-functional defects
-Test Automation Engineer: Designs a test automation ecosystem & writes and maintains test scripts for automated testing
– DevOps Engineer: Facilitates cooperation between development and operations teams & builds continuous integration and continuous delivery (CI/CD) pipelines for faster delivery
– Business Analyst: Understands customers business processes and translates business needs to requirements.
– Project Manager: Makes sure a product or its part is delivered on time and within budget & manages and motivates the software development team
– Project Owner: Holds responsibility for a product vision and evolution & makes sure the final product meets customer requirements

Infographic illustrating the challenges of managing software development teams, including communication, role clarity, and meeting deadlines.

Post-team assembly

Depending on your project you now have an idea on what team you have, the next step is actually managing them. This entails setting clear objectives/goals, creating a timeline, allocating resources, setting communication strategies, delegating, implementing, tracking progress, monitoring project, managing risks/challenges & maintaining flexibility.

Overview of a project manager’s essential roles and responsibilities in software development.

Final thoughts

I now have a better understanding the importance of team management in software development. In order to maximize efficiency towards a project/goal you definitely need to manage a significant amount of aspects related to development. The ability for a team to work together is also valuable & must be taken into account. Overall, I really enjoyed researching this topic, the main sources I used in my research was this section in Atlassians website as well as this section in the itrexgroup website.

From the blog Petraq Mele blog posts by Petraq Mele and used with permission of the author. All other rights reserved by the author.

CS343-01: Week One Blog

Software Constr – Week One

For week one’s blog, I read the article I first found, Software Architecture Recommendations By Mark Richards. I wanted to start off with something I’ve found first before potentially either diving into more research for videos and articles or maybe even going through what my classmates have found for inspiration.

In Software Architecture Recommendations By Mark Richards, it features a software architect named Mark Richards who covers his definition of software architecture along with the key soft skills and responsibilities of an architect. There are two aspects of software architecture in his vision, as structure and as process. “Within the structural aspect of software architecture there are 4 dimensions: architecture characteristics, architecture components, architecture styles, and architecture decisions.” He mentions how there are soft skills and techniques which include negotiation, facilitation, and leadership when it comes to the process aspect he sees in software architecture.

He says that negotiation is a required skill since “almost every decision you make as an architect will be challenged. Your decisions will be challenged by other architects who think they have a better approach than you do; your decisions will be challenged by business stakeholders because they think your decision takes too long to implement or is too expensive or is not aligned with the business goals; and finally, your decisions will be challenged by development teams who believe they have a better solution.” Which makes sense since if you want to do your job, people will think what they have to say is better, more efficient, etc. So you do have to understand the political climate– as the article says– and how to navigate it to get the views and decisions you made both approved and accepted.

Facilitation is another “soft skill” that Mark Richards thought of where the architects don’t only collaborate with development teams. He says that they should also collaborate with various business stakeholders to understand a number of things such as “business drivers, explain important architecture characteristics, describe architectural solutions, and so on.” Upon further research, I found that facilitation is a shift in the architect’s role from a central decision-maker to a facilitator who empowers the development team to make architectural decisions collaboratively, so it’s a tool to have to keep things on track.

And then there’s leadership. The architect in Mark Richards’ mind is responsible for leading and guiding the development team through implementations. “They are there as a guide, mentor, coach, and facilitator to make sure the team is on track and is running as smooth as a well-oiled machine, and to be there when the team needs clarification or has questions and concerns about the architecture.”

Reading this from his perspective and his opinions are an interesting way of learning his job as a software architect since he has the experience and he has learned from the mistakes he’s made. It’s an important thing to know that even though it’s his job, he’s always learning about ways to improve and for him to share this knowledge is something that’s valuable since you can take the advice and knowledge given and apply it to your own job.

Source: https://apiumhub.com/tech-blog-barcelona/software-architecture-recommendations-mark-richards/

From the blog CS@Worcester – The Progress of Allana R by Allana Richardson and used with permission of the author. All other rights reserved by the author.

CS348-01: Software Process Management

The Beginning

This is the beginning of my documentation in my class CS-348 and phase two, part one, I suppose, for CS@Worcester with the work that I was able to accomplish, had trouble with, and solutions I found.

It’s kind of like my last blog, except new class equals new puzzles I’ll experience!

From the blog CS@Worcester – The Progress of Allana R by Allana Richardson and used with permission of the author. All other rights reserved by the author.

CS343-01: Software Constr, Des & Archit

Software Constr – First Steps

This is the beginning of my documentation in my class CS-343 and phase two, part two, I suppose, for CS@Worcester with the work that I was able to accomplish, had trouble with, and solutions I found.It’s kind of like my last and now current blog, except new class equals new puzzles I’ll experience! I really hope to do well, even with quizzes or exams as a sort of weak spot for me.But hopefully, with enough reading and practicing, I’ll do well. I want to do well. I’m aiming to do well.

From the blog CS@Worcester – The Progress of Allana R by Allana Richardson and used with permission of the author. All other rights reserved by the author.

Spies and Their Role in Software Testing

As I was doing some at home research on stubs and mocking for one of my courses, I came across the idea of spies. Unlike stubs and mocks which allow for the program and tests to run while giving canned answers or being unfinished, spies perform a much needed but previously unfilled role.

Spies are used to ensure a function was called. It’s of course more in-depth than this but that’s it’s basic function.

On a deeper level a spy can not only tell if a call to function was made, but how many calls, what arguments were passed, and if a specific argument was passed to the function.

Abby Campbell has great examples of these in her blog, “Spies, Stubs, and Mocks: An Introduction to Testing Strategies” where she displays easy to understand code. I would definitely recommend taking a look at them, her blog also goes in depth on stubs and mocking.

When writing test cases, the addition of a spy to ensure a thorough case can’t be undersold. Imagine a simple test case that uses a stub, without the use of a spy you can’t be sure the correct function was called unless every function returns a different value which would be inefficient to set-up. By using a spy the function called is checked, the argument passed is checked, and the output can even be checked as well leaving little to no room for an error in the test case aside from human error.

With the addition of spies to our arsenal of tools for software testing we check off the need to find a reliable way of testing for ensuring correct function calls and arguments. I plan on carrying this new tool with me throughout the rest of my career. It allows for much more efficient, effective, and sound testing.

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

The Importance of Quality Testing

By Daniel Parker

When I say quality testing many software developers and others in the computer science field may think I am referring to testing the quality of software. While in many instances this may be the case, here I would like to point out the importance of quality testing; or creating tests with a high level of quality to ensure working software.

Before delving into why it’s so important it might be beneficial to highlight just how disastrous dysfunctional code can be. According to Harry Ngyuen in his blog “Top 8 Reason Why Software Testing Is Important In 2025“, fixing a bug that has made it the maintenance phase can cost 10 times more to fix than it does during the design phase.

As he also mentions many customers expect fast and high-quality applications and if these expectations are not met many customers may switch their provider. As well as customer satisfaction many risks can come with buggy software creating security hazards.

Clearly having buggy code that was haphazardly tested is incredibly detrimental to any software being released by a single developer or even an entire organization. So how do we ensure this doesn’t happen?

There is a magnitude of ways to test code, and I don’t think listing them out will help with our cause as there is no best way. To ensure high quality software you mut write high quality tests.

Your tests have to be able to accurately track the flow of your program, be able to highlight where something failed and why it failed, and ensure all boundaries are tested and a successful output is what you’re left with. This means writing as many tests as needed, whether its five or fifty. It means writing tests that check whether your application can handle anything thrown at it. Testing can take time and effort but it’s much better to spend that time while writing your code and handling the bugs one at a time than to have to deal with many after a release has occured.

I plan on continuing down the road of software development both in my student career and my professional career. With this in mind, I will ensure I apply my quality testing skills to produce the highest quality software I can.

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