Category Archives: CS-343

Technical Debt

Technical debt is a programming theory that refers to the necessary work that gets delayed during the development of a software project to meet a deadline or deliverable. It is an idea that shortcuts are taken to quickly deliver a product, but this decision incurs a “debt” that must be paid in the future when the work is eventually completed. Technical debt is often the result of a tradeoff between perfect products and the short timelines often required for product delivery. Developers may choose the easier route with messier code or design to deliver a product faster, but this can lead to technical debt that must be addressed later.

Technical debt can accumulate “interest” over time, increasing the difficulty of implementing changes and leading to software entropy. It is important to manage technical debt to avoid these negative consequences. This involves identifying technical debt, accounting for nonfunctional requirements, and implementing best practices and agile practices to minimize it. It is also important to be proactive in reducing technical debt in new initiatives by carefully planning and designing projects from the start.

I selected this post because I wanted to learn more about technical debt as I found the concept to be particularly interesting and relevant to my future projects. This topic also seemed important as I found it amazing that despite the large file structure for projects in this class, it was not too difficult to add and update code for the assignments. That showed me how a codebase can avoid technical debt to a degree, and how it simplifies for maintainers (or a group of students) the process of adding and updating code to the codebase. After reading through the blog, I gained a better understanding of what technical debt is and how it can accumulate over time. This really resonated with me as I can see how important it is to consider the long-term implications of the decisions, we make during the development process. One of the most valuable takeaways for me was learning about the various types of technical debt and how to identify them. This will be especially useful as I continue to learn and grow as a programmer. I also appreciated the discussion of best practices and agile practices for managing technical debt, as I can see how these approaches can help to minimize the amount of debt that is incurred. I expect to apply what I learned in my future practice by being more mindful of the potential impacts of my decisions and actively working to minimize technical debt whenever possible.




From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.


KISS is an American rock band formed in New York City in 1973. The band is known for its elaborate stage shows, which often feature pyrotechnics, fire breathing, and other special effects, as well as the use of makeup and costumes by the band members. In all seriousness…

The KISS principle, or Keep It Simple, Stupid, emphasizes the importance of simplicity in design and systems. By keeping things simple, you can better understand and meet the needs of customers and create products that are more user-friendly and effective. In the world of software and technology, the KISS principle is especially important, as people often have many options to choose from and may not understand complex technology. By following KISS, you can build a minimal viable product (MVP) that allows you to confirm or disprove your hypothesis with minimal work and deliver your product in a straightforward way that is easier for users to understand. Amazon, for example, lists the KISS principle as a core leadership principle, stating that leaders should always find ways to simplify. When designing, it is important to wireframe religiously, use universally understood concepts, and avoid distractions. By following KISS, designers and developers can create products that are more efficient, effective, and user-friendly, and that are easier to maintain and update over time. The KISS principle is often applied to the design of systems and user interfaces, as well as to the development of code and algorithms, to create products that are intuitive and user-friendly.

I selected thispost because I have always been interested in the principles of good design and how they can be applied to create better code as a result. The KISS principle is a concept that I have heard of before in other classes and especially in the Robotics class last semester. I wanted to learn more about this principle and after reading this post was impressed by the emphasis on simplicity and how it can lead to better products and user experiences. The post also focused heavily on real world applications and its outcome which helped me visualize it better. I found this material to be very informative and made me think about how I can apply the principles of simplicity and user-friendliness in my own projects and for other CS classes in the future. I expect to use what I learned from this resource in my future practice by being mindful of the KISS principle and always striving to create products that are simple, efficient, and user-friendly.




From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.

Whats Next?

I have had this unhealthy assumption in my mind that CS is just preparing us to just sit at our desk all day and write code for hours upon hours(at least in the industry context). Although, in the cases where this may be true, for those that are in that position, there may be a good chance that they are doing what they enjoy. I don’t see this being the entire case for me. Knowing this, a couple questions and thoughts come to mind; in exploring different roles one can play in the tech industry, where may my own opportunities lie? Can I recognize what I am learning in relation to that, maybe even evaluate how/what I am learning to where I might see myself? Can I map out my career?

I think it is important to ask such questions while taking these CS courses. While asking such questions during the courses I can recognize where my strengths may lie and discover possible passions/interest. I am prone to overthinking(especially with complex ideas) and such practices allow me to step back a little. Going off previously stated questions, there is something about the front-end that is quite alluring to me. Which leads me to an article that I found titled “Exploring the front-end of project management”

Although it doesn’t talk about specific front-end development tools, (a topic in which I would like to look more into) and more so on what comprises the front-end and the role of management, it is a exploration into the front-end, or defined in the paper as the “earliest stages of a project”.  I think that the article is still relevant as we can recognize that the POGIL group work style of the class allows students to be able to work in groups, the prevalence of different roles is to almost simulate the professional setting in which on may work. This style teaches students to be able to work well with others and communicate very complex ideas. I personally find a lot of enjoyment in working in groups and struggling and learning together, specifically; exploring and playing with the different roles from manager to presenter, working through unexpected situations through analysis and modification, and sharing finding with the entire class. From my brief research, the front-end to me seems to be where I can explore not only different roles but explore even more broad experience from different aspects of the tech industry.

On a different note, I made an observation in my last post about the nature of the learning that is done in CS and how topics can connect. I described that connection of topics as niches. I wanted to make a correction and niches may not be the right word. Perhaps, layers, at least in the context of this class I could argue that front-end being a layer in software development is more suitable. If anyone gets what I am trying to say and can find a better way to word it, please let me know.

From the blog CS@Worcester – Sovibol's Glass Case by Sovibol Keo and used with permission of the author. All other rights reserved by the author.

Blog Week 14 (Token)- Abstraction and Composition

The Two of the fundamental aspects of coding, Abstraction and composition, are discussed thoroughly in this blog as well as the overall impact these processes can have on the code as a whole, we discussed these two towards the beginning of the classes and how they have there rolls in being able to not only code better but to understand and lay out the structure of the code.

At first I didn’t really understand how reducing a problem to its most basic form could help when I need to make code to very Specific actions and work a certain way, however after utilizing those processes in order to simplify the problem, then follow up by building up from those basic models allows me to utilize basic code to solve my more advanced problems. This opened up my thought Process when it came to Writing code as now I could think of all of the previous Projects I had where I had to create multiple objects and set Attributes for each specific one, and now I could seamlessly do it on a larger scale reusing other basic code.

For abstraction, it is the process of reducing all of the but the most important details in the code and leaving all of the extra out, it is important as it all owes for the most basic process to be worked on, and then subsequent work can be delegated to the more advanced versions of that the problem. an Example would be to rather than making multiple functions for different things, we could makes basic function that can be implemented repeatedly and reused. We can look at an example of the duck Project where we looked at different models of these classes and we noticed that certain ducks needed specific flying actions or squeaking actions, so rather than making multiple classes for multiple different types of ducks we made a basic duck class and created specializations for them In order to better the overall structure and reduce clutter. Then the using Composition you may make the connections to the different Objects in order to share information. Using the Duck Project Again, we made different types of ducks with Connections being made to the main Duck class with all of the Parameters, then we made connections for the squeak and Fly behaviors.

The Writer Focus on some key Traits for Good Abstractions, that being Simple, Concise, and Reusable. These are the things to look for when you want to simplify the work you do.

Elliott, Eric. “Abstraction & Composition.” Medium, JavaScript Scene, 28 May 2020,

From the blog cs@worcester – Marels Blog by mbeqo and used with permission of the author. All other rights reserved by the author.


This week I learned about concurrency in software. I read “Concurrent Programming Introduction” by Gowthamy Vaseekaran. Vaseekaran explains what concurrency is in programming as well as its positives and negatives of it. Overall it was an interesting post to read and I think it gave me a better understanding of how computers work.

Vaseekaran starts by explaining concurrency is the ability to run several programs or parts of a program in parallel. This can be a huge benefit for performing a time-consuming task that can be run asynchronously or in parallel. Vaseekaran then goes on to explain the reasons that led to the development of operating systems that allowed multiple programs to execute at the same time.

These factors are resource utilization, fairness, and convenience. Resource utilization is needed because when some programs have to wait for external operations there is downtime that could be used to let another program run. Fairness is when multiple users and programs have an equal claim on the computer’s resources. It is more beneficial to let them share the computer through finer-grained time slicing than to let one program run until it is down and then start the next one. 

The next thing Vaseekaran brings up is threads. Threads are a series of executed statements that are lightweight and have their own program counter, stack, and local variables. Threads are used to help run background or asynchronous tasks. They increase the responsiveness of GUI applications and take advantage of multiprocessor systems. Java uses at least one thread when running. Threads help java run more smoothly but there are risks. The main risk is when there are shared variables/resources. Deadlocks can also happen when threads are used and multiple processes get stuck waiting for each other.

This was a good amount of information to learn and I think Vaseekaran did a great job explaining what concurrency is and its ups and downs of it. Starting with the reasons why we use it and then explaining how it is useful for a programming language like java was a good way to make it easy to understand what it is and how it is used today in software development. I think it would be interesting to learn more about how threads can be used in java. Vaseekaran’s post was useful for understanding concurrency and what threads are but how exactly a java developer implements them was very brief here. I would like to know more about how that works exactly but this was a good introduction to the topic and was an easy read. I would definitely recommend Vaseekaran’s post to anyone trying to learn more about how software is run and how to make it efficient. 


From the blog CS@Worcester – Ryan Klenk's Blog by Ryan Klenk and used with permission of the author. All other rights reserved by the author.

Thoughts on Front-End Development

I often find it hard to relate back to other courses and easily forget about what I have previously learned. Luckily, my memory is not as bad as I think it is and it eventually comes back to me, especially in the case where I have to come back to a skill/technique regularly. I find that with Computer Science the evolution of knowledge is one that is clear yet has a depth of knowledge that intertwines one course with the next.

On one hand, you can have a course that is so specific in a niche of CS that it may be hard to see its relevance in another CS course on the other hand you may have a course that is seemingly so broad that it is hard to pinpoint how it may carry over.

I think that with any specific area of interest, as one continues with their education, the degree to which prior knowledge is necessary and relevant to learning a new topic only increases the further you progress.

All this is to say that last semester I took a cloud computing course and I remember that course being broad in its application of cloud computing. I wanted to look into the use of cloud computing in the context of software design and architecture. Secondly, after only getting a taste of front-end development in this course I wanted more and I wanted to solidify my understanding of the back-end and front-end in an attempt to satisfy a goal of mine described in a previous blog post.

Overall I’m not seeing any major differences between implementing software through the cloud vs other options other than the vast benefits that cloud computing can offer. Benefits of cloud computing range from storage, server, database, software networking, intelligence, and analytics. The blog begins with describing what cloud computing is then goes into detail about what front-end and back-end cloud architecture is along with cloud based delivery.

I was then led to another blog about specifically front-end development as I was not satisfied with what the previous blog provided. This blog hooked me with its first line saying “Front-end developers need to design sites that are engaging enough to nudge the target audience toward a conversion.” I find this idea to be very interesting because it starts to dive into the purpose of front-end development.  In my next post I will discuss where I may see myself in the future and what role I might want to play in the tech industry. There is a point in the blog in which the duties of a front-end developer are laid out leading to an intrigue and wonder about whether this is a niche in CS where I may see myself, in front-end development I feel it might be a role in which I can use a variety of skills/techniques in order to develop myself.

From the blog CS WSU – Sovibol's Glass Case by Sovibol Keo and used with permission of the author. All other rights reserved by the author.

Overcoming Anti-Patterns

This week I encountered a blog regarding Anti-Patterns. As we have learned, design patterns are reusable solutions to common problems and provide a way for us developers to solve problems in a proven way, rather than trying to reinvent the wheel every time a problem was to arise. On the other hand, Anti-patterns are unhelpful or ineffective approaches to problem solving that can negatively impact the efficiency and effectiveness of our work. 

Some common examples of anti-patterns include:

  1. The Golden Hammer, which is when a specific tool or approach is overused or applied to every problem. I can personally say that I’ve fallen into this trap as I would always use the same programming language or framework to write code and would come to a standstill not knowing what to do next. Little did I know there were more suitable options that could’ve made my job easier and the end product more efficient.
  2. The God Class antipattern, occurs when a single class in a software system becomes excessively large and complex, with too many responsibilities. I believe all developers including myself, at one point or another, created a class with too many responsibilities and would wonder why we have issues in our code. This would even violate the Single Responsibility Principle as each class should only have one key responsibility. 
  3. The Big Ball of Mud antipattern, is when a solution lacks a clear and flexible architecture. As a program developer, I’ve encountered the big ball of mud antipattern and it can be a major source of frustration and inefficiency. Working with a system that has become a “big ball of mud” can be extremely difficult, as it can be nearly impossible to understand how the different parts of the system fit together and what each component is responsible for. This can make it difficult to make changes to our code, as it is unclear how those changes will impact other parts of our code.
  4. The Copy and Paste Programming antipattern, is where code is copied and pasted from other sources without proper understanding or modification. I believe every programmer at one point found code that they believed they could reuse from another program and placed it into their new program. The program may work, but it causes many bugs and becomes difficult to later make changes. 

Overall, as important as design patterns are to follow, sometimes we will fall into the trap of an antipattern. In my own experience, I have fallen into the trap of using anti-patterns in my code. Now knowing how to avoid these patterns going forward, I’ll be able to recognize and avoid antipatterns and leverage design patterns that can help to create more effective and efficient code. By doing so, anyone can better achieve their coding goals and improve the quality of their work.

From the blog CS@Worcester – Conner Moniz Blog by connermoniz1 and used with permission of the author. All other rights reserved by the author.

Blog Week 14- Good Software Technical Writing

One of the most Relevant and important aspects of programming that I have neglected for a while is commenting and proper technical Writing, when I first started out I figured I would just remember all of the changes I would make to my code and didn’t require the small notes in-between methods. later on I began to understand the importance when I began working with many different files that needed to work in tandem and couldn’t remember what each method I wrote did or how it worked in the system as a whole.

In this blog the author Goes over many of the different aspects of technical Writing from either commenting on each method to adding context to the code overall, the biggest take away I got from it is that code without Comments is Worthless, by reading the documentation you should be able to understand why the previous engineers made changes or added functionality to the code. this allows for other developers to come in and quickly understand what is going on and be able to delete or insert sections of code in order to continue the development cycle.

the Writer goes on to show many different examples with one being a sequence diagram that gives the step by step explanation of what the Sequence of the systems in play, much like the different design architectures we discussed in a previous class where it shows the link between user and the database. The Importance of this kind of writing is that it can convey the was the system is supposed to work together so if another developer were come along and look over the schema they would understand the process and be able to work off of that.

Oliveira, Vincent. “HOW TO WRITE Good Software Technical Documentation.” Medium, Medium, 15 June 2022,

From the blog cs@worcester – Marels Blog by mbeqo and used with permission of the author. All other rights reserved by the author.

Some APInions on REST and GraphQL

Whenever you’re new to a thing, a comparative look at different tools can help you understand the problem by learning how each tool approaches a solution. As someone new to consuming and designing APIs for the web, I’m interested in understanding APIs by looking at the difference in approaches of the REST specification and the GraphQL query language. This post is based on Viktor Lukashov’s GraphQL vs. REST blog post, which explores some GraphQL basics from the perspective of a REST API user.

Priority: server-defined endpoints or client-defined queries

The largest difference mentioned by most sources is that a well-built REST API relies on extensive backend definitions of endpoints, while GraphQL puts the onus on the consumer to carefully query the correct data.

In REST, accessing multiple entities requires visiting an endpoint for each entity. These endpoints expose data through predefined parameters and responses. Meanwhile, GraphQL exposes a single endpoint while only returning data that corresponds to the consumer-defined query. This approach requires higher effort from the user, but allows them to construct tailored queries without the need for forethought from the API designer.

As a fan of query languages, I think this comparison is very favorable to GraphQL. For any interesting or useful dataset, a user exploring the data should have more ideas about how to observe it than its maintainers and gatekeepers will. Providing flexibility for query writers lets your interface be used in ways you can’t predict.

Implication: caching and performance

One upside of REST’s focus on a planned set of endpoints and parameters is that expected frequent responses can be use HTTP caching to improve performance. Responses to GET requests will be cached automatically, reducing server requirements and potentially improving response speed for future identical requests.

In GraphQL, the query writer is responsible for using a unique identifier to generate useful cache data. That said, the consumer may be able to use single queries across multiple tables that would require more than one REST API call to access.

Relying on architecture over following best practices is probably the better way to make performance accessible, which is a point in favor of REST.

Consequence: rules and security

Another difference Viktor mentions is how developers implement secrurity rules. REST’s default to the expansion of endpoint-HTTP method combinations includes setting rules on this basis. In GraphQL, with it its single-endpoint, rules are instead set per field. This may require a steeper learning curve, but it also provides more flexibility for easily making some attributes of an entity more available than others.

Conclusion: rigid or demanding

One recurring theme of this comparison is that REST APIs are built to be rigid, and another is that GraphQL requires higher effort from the client. This is how I would decide between the tools. If writing something that I expect to be querying frequently myself in new ways, I’d want the query freedom offered by GraphQL. If I wanted a small and fixed feature set, REST seems like the spec to follow.

From the blog CS@Worcester – Tasteful Glues by tastefulglues and used with permission of the author. All other rights reserved by the author.

Smells and Senses

I want to focus this blog post not on something that I’m interested in but rather something I think that I should know. I decided to put some more research into design smells, this topic seemed valuable because I have this perception that understanding and looking at code is not a skill that I have yet to developed. I wish to improve upon this, so I found this presentation on code refactoring and design smells that is pretty in depth and it goes into a little more detail about what we had discussed in class. In the class activity we connected technical uses of the word to technical definitions based on our understanding of the common definition. This activity provided a basis for understanding different smells. This led me to find a higher-level presentation on design smells and grasp some level of understanding of what was being discussed. In the video the speaker Sandi Metz suggests that when you can identify a code smell you can then refactor the code to better suite future use. What refactoring is, is the ability to rearrange code without changing its behavior. The ability to look at code and associate information is exactly what I am looking for.

There were a couple of ideas that stood out to me. The presenter offered an analogy that stood out to me that  refactoring is kind of like a recipe. Sandi then provides a valuable resource that maps specific code smells to a reference in Martin Fowlers book , a refactoring recipe that is “curative”  to that code smell. This leads me to another suggestion that it is okay at some level to “own your code smell” if it is working and won’t change in the future. This reference to Martin Fowlers books immediately reminded me of his very informative blog. The book itself seems very interesting to me and could potentially offer a wealth of valuable knowledge that could vastly improve my abilities.

As an avid home cook this analogy spoke to my soul, all this talk of smells and recipes sparked an understanding of code that I was not familiar with. In my journey as a home cook, I have been exploring the ability to make food more creatively as instructed by a transformative cookbook that I have been reading. There is an idea that I have been working on that suggests not following a recipe and relying on your senses and being actively involved to create a wonderful dish. I find that this relates heavily to my journey in becoming a software developer, taking information from outside resources and interpreting it in a practical way all while relying on my senses and built intuition.

From the blog CS@Worcester – Sovibol's Glass Case by Sovibol Keo and used with permission of the author. All other rights reserved by the author.