Author Archives: Daniel Parker

Good Software Design and the Single Responsibility Principle

The single responsibility principle is simple but critical in good software design. As Robert Martin puts it in his blog The Single Responsibility Principle, “The Single Responsibility Principle (SRP) states that each software module should have one and only one reason to change.” He also does a great job of comparing this to cohesion and coupling, stating that cohesion should increase between things that change for same reason and coupling should decrease for those things that change for different reasons. Funnily enough, while I was reading a post on Stack Overflow I ran into this line, “Good software design has high cohesion and low coupling.”

Designing software is complicated, and the program is typically quite complex. The single responsibility principle not only creates a stronger and smarter structure for your software but one that is more future-proof as well. When changes must be made to your program, only the pieces of your software related to that change will be modified. The low coupling I mentioned earlier will now prevent the possibility of breaking something completely unrelated. I couldn’t count the number of times my entire program would break by modifying one line when I first started coding, because my one class was doing a hundred different things.

This directly relates to what we’re working on in class right now. We are currently working with REST API, specifically creating endpoints in our specification.yaml file. Our next step will be to implement JavaScript execution for these endpoints. When we begin work on this keeping the single responsibility principle in mind will be incredibly important. It can be very easy to couple functions that look related but change for completely different reasons. For example, coupling validating new guest data and inserting the new guest into the database. While they seem very related, they may change for very different reasons. Maybe validation requirements change, causing the validation process to be modified but not the inserting of a new guest. The database structure or storage system may change leading to modifications to how the new guest is inserted but not how they’re validated. Keeping in mind that related things may change for different reasons will be key for my group leading into the next phase of our REST API work.

This principle is one that I plan on carrying with me during my career as a programmer. It will help me create more future-proofed programs in a world where things must be ready to constantly evolve and adapt. Uncle Bob’s blog was incredibly useful in my understanding of this principle on a deeper level. I feel like a stronger programmer after just reading it. I look forward to implementing what I’ve learned as soon as we start working with the JavaScript of our REST API.

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

Refactoring and its Importance to Software Design

In my software construction, design, and architecture class we’ve focused a lot on (believe it or not), the design and structure of software. Software is typically quite intricate and designing it as efficiently and cleanly as possible is almost never accomplished the first time it is coded. “Code Refactoring and why you should refactor your code” by Lazar Nikolov is a great blog dedicated at explaining what refactoring is, why you should use it, and when you should use it.

Refactoring is just the process of identifying technical debt and code smells withing the existing program and modifying the code to be more optimized removing these issues without changing the user interface behavior. As Nikolov describes there are many objectives of refactoring such as increasing readability, maintainability, reusability, optimizing the performance, and enforcing code standards. There are many situations you should consider refactoring in. Such as DRY where you find and replace repetitive information with an abstraction that is less likely to change, or when working with someone else’s “bad” coding that you need to build on.

The key takeaway here is that no programmer does the job perfectly the first time. Programs constantly evolve and have changing specifications that must be met. A good programmer is one who can roll with those punches and change the code as needed. Our most recent homework assignment really focused in on this and had us refactor the code we we’re working with three different times each time using a different architecture. In doing so we learned each time how the previous code could be improves upon to function better and with less bugs even though the original code worked fine. Moving from the strategy pattern to the singleton pattern lastly to the simple factory pattern allowed us to see how each new version after refactoring solved a different problem from the previous. Even though they all worked fine we could see the optimization occurring.

Refactoring is certainly a concept I plan on carrying with me into the future. I’m not sure if there’s a good programmer out there that doesn’t use this concept constantly. Having the ability to constantly adapt my code to best suit it to not only its current task but any future ones that may arise is an incredibly good skill to have. I know it will help me not just as a student at Worcester State but as a professional software developer someday too.

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

Why Polymorphism is so Important in Programming

Polymorphism is one of those terms you hear in Computer Science that sounds confusing at first and overly complicated, until you find out you’ve probably been using it this whole time. “Polymorphism in Programming” by Johnathan Johnson is a great blog detailing exactly what it is and how it works. It gives a nice clear definition that’s easy to understand and then lists out the different types you’ll encounter along your programming journey.

Polymorphism is essentially just a process that can perform multiple tasks depending on the context of the situation. There are many forms of polymorphism as well such as Subtype (Runtime), Ad hoc (Compile-time), Parametric (Overloading), and Coercion (Casting). I won’t get too in-depth on each of these as Johnson has already done a great job of this in his blog.

The key takeaway here is that polymorphism allows you to program an interface, not just an implementation. What I mean is by creating an interface or superclass it doesn’t matter what type the object being called is you can just call the method on it. For example, you could have a list of Shape objects that can hold a circle or a square or whatever shape you want, and you can call draw() without caring which specific subclass you’re dealing with. Because of this code duplication can be severely cut down due to multiple objects using the same method all stored in the superclass.

This is similar to what we saw in class with the Duck superclass and all the subclasses with different duck types. As long as you were calling a method stored within the superclass it didn’t matter which subclass you were calling it on. Even if the subclass had overridden the method, you would just be running into ad hoc polymorphism as the program would be switching the version of the method used to that of the one stored in that particular subclass.

Even though I’ve been using polymorphism for years through my career here at Worcester State it’s good to finally learn what this practice is actually called. It’s also good to learn that there are forms of it I wasn’t always using when I could of and instead took the less efficient route to solve my problem. The concept is integral to time efficiency and when programming time is incredibly important in a lot of ways.

I plan on taking this newfound knowledge with me through the rest of my career here as well as whatever the future holds for me.

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

Introduction for CS343

Hello, my name is Daniel Parker, and I will be using this blog for the duration of my time in CS343 or software construction, design, and architecture.

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 Teamwork in Software Testing

While teamwork may not be listed as one of our topics for the course, if I’ve learned anything during this semester it’s that teamwork yields massively more results than testing alone. We just recently did an assignment where we were given “shaky” code to look at and record any errors we found. We started by going off on our own to look for errors. We then came back together to see what everyone found, and it was amazing how different our lists look. Even though it was the same code everyone caught a ton of different mistakes.

There are plenty of benefits to teamwork in the software testing field. “The Importance of Collaboration in Software Testing Teams” is a great blog I discovered that fully goes over these benefits. Unfortunately, the author did not leave their name anywhere and signs off as “admin” so I can’t give them the full credit due, but I linked the blog above if you want to give it a read over.

Some key takeaways are early issue identification, improved software quality, and increased efficiency. There’s many more listed in the blog, but these are the three I find most important.

In one of my previous blogs, I mentioned just how much more it can cost to fix a mistake that slips through the early phases of software development so having early issue identification is huge. Through multiple eyes looking at the same software everyone is able to use their own unique perspective to weed out as many bugs as possible.

As for improved software quality and efficiency, how can you not say yes to better software, faster. That’s just a win for everyone. Every developer has their own style and methods to solving problems and by combining them you can create innovative solutions that can drastically increase efficiency while creating more sound programs.

Teamwork has been a large part of my computer science degree at Worcester State. I plan on continuing to sharpen my skills as both an individual and a teammate as I progress through my career both academically and professionally.

From the blog CS@Worcester – DPCS Blog by Daniel Parker 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.

Why Boundary Testing is so Important

Boundary testing is an integral aspect of testing software used to test the extreme limits of a program. It consists of testing the minimum value, right above minimum, a nominal value, a maximum value, and right below maximum. If we’re using a strong testing method, we would also test below the minimum and above the maximum.

By testing this way, we can assure that the “boundaries” of the program work correctly as well as center of those boundaries. We can also ensure that invalid inputs return an invalid response from the program.

As Jayesh Karkar says in his blog “Everything You Need to Know About Boundary Value Testing”, “This testing is imperative when it comes to testing the functional competence of software modules.”

He mentions some factors that justify the necessity of boundary value testing. These include that functionality errors are likely to occur more often at boundaries, it only tests a small range of values making it simple to execute, and due to the testing being based on guidelines and framework there is no chance of compromising the boundary values which ensures maximum test effectiveness.

Now as most of us in the computer science field know, there are many ways of testing programs. Boundary value testing is just one of them. With this in mind, boundary value testing is certainly one you should keep in your “tool kit” and combine with other forms to create the most effective tests possible.

As I continue my career as a student and my future career as a computer scientist, I plan on taking this form of testing with me wherever I go as a fundamental.

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.

Why Clean Code is so Important for Workflow

When coding there are a lot of factors to consider, the time complexity of your algorithms, the space complexity as well, and even power efficiency can all affect the decisions you make and the flow of your program. It’s a complicated task and with constant distractions in our ever-growing busier and busier lives the need to make the coding process as quick and easy as possible is constantly present (of course it almost never is quick and easy).

One way that we can optimize our time effectiveness is clean code. What is clean code? As Thiraphat Phutson puts it in his blog, “The Art of Clean Code: Writing Code that Lasts“, it’s code that’s easy to understand, maintain, and extend.

There are plenty of aspects to writing clean code such as using good naming schemes for variables and functions, proper spacing, consistent indentation and bracket use, the list goes on and on. And just like there’s many aspects of clean code there’s plenty more attributed to “messy” coding.

So how does clean code apply to me? As a major in computer science the ability to code is almost the entire point of my degree. Learning how to keep my code clean and organized, making it easier for myself to understand if I ever need to come back to it as well as fellow team members and coworkers is incredibly important.

As I’ve mentioned my honors project in my past few posts, I’ll mention it again here. Although as I’m writing this my project has been submitted and is officially done in terms of what my professor will see for now, I’m not done with it. In fact, I’ve barely begun. Most of my honors project was geared around performing my own sprint for a product I’ve chosen to create. In the first sprint I completed almost no coding got done, most of it was setting up to be able to start programming the project.

This is where I can take the clean code skills I’ve acquired, and make sure that as I’m coding what I can only imagine is going to be a very complex project I’m keeping it organized and efficient. As Phutson mentions, clean code allows for maintainability, scalability, and efficiency, all things I’ll need for my project. He also mentions collaboration which is another fantastic aspect of writing clean code, but it doesn’t apply as much to my case with me being the only developer.

Clean code is an incredibly important skill to have in the computer science world and I’m grateful to have had not only an introduction to it but some practice with it as well. I will be sure to keep it ever-present in my mind as I code not just my current project but any project in the future.

, ,

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

Performing a Sprint Retrospective

A sprint retrospective is an event that occurs at the end of a sprint where the team meets to discuss improvement for the next sprint. This is to say, the team gets together and looks back at the sprint completed and looks for areas of improvement that they can adjust for the next sprint.

Following the theme of my last few blog posts, I will be manning a one-man scrum team (which is an odd sentence). How exactly will a sprint retrospective look for me and by extension how would it look for someone following a similar journey through scrum?

A great place to start is knowing what’re the right questions to ask, thankfully Rodrigo Ribeiro has provided us with these questions is his blog, “How to Run a Sprint Retrospective 101: The Essential Guide”. Now, this blog was written with an entire scrum team in mind so let’s take a look at the four major questions he poses for a retrospective and look at them in our scenario.

“What did you like in the sprint?”

This is a simple question, but it may have more significance to our situation than you would think. As Ribeiro notes this section is mainly for giving credit where credit is due to your team members and making sure to thank them for their efforts. Well for us we are our team members, but that doesn’t mean we don’t deserve credit or appreciation for our effort. Taking a moment to pat yourself on the back for completing your sprint and telling yourself you did a good job can really improve your attitude and confidence when looking towards the next sprint.

“What is puzzling you right now?”

This question is an opportunity for your team to ask for clarification about roles in the team, as well as technical and functional purposes. For us, roles are not relevant as we are assigned all of them. As for technical and functional purposes, as the product owner we already know what the purpose of our product is, both technical and functional as we’ve designed the backlog. With this being said, maybe this question is better omitted from out one person retrospective.

“What didn’t work so well?”

This is the time for the team to express their feelings about the project. In our instance, this is the perfect opportunity to be fully honest with ourselves about our current feelings towards the project as well as our feelings about that last sprint. Were there issues with backlog items? Did we move the project towards completion in the same direction we set out product goal? These are very important questions to ask ourselves and to be fully honest about as we’re the only input.

“What are your improvement ideas?”

This is the section where you, of course, should ask your team for solutions to issues you’ve been having as well as general ideas for project improvement. So how does this relate to us? After the end of our previous sprint, with certain backlog items finished and maybe even some scrapped, some adjusted, and some still alluding a solution, we can take a minute to reassess our current situation and decide our next steps. Were some of the completed backlog items not completed to our standard, or in the direction we wanted to move our project? Are some backlog items unable to be completed now irrelevant or should a new way of looking at them be implemented. Without the input of others during a sprint it can be hard not to be one track minded and tunnel visioned so this is a great opportunity to take a breather, relax, and try to search for a new angle. Maybe write down some solutions, think them through, and try again with new tasks and backlog items for the next sprint.

It’s important as a one-man scrum team to be incredibly flexible, and getting held up on one backlog item can really stagnate progress and burn out a single developer. Asking these questions in the middle of the sprint will only lead to complicating something that’s already complicated navigating as one person. It’s better to do what you can during the sprint and assess and reevaluate with yourself after. From there you can make changes and move forward in the direction of your choosing.

, ,

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