Category Archives: Week-15

Understanding Technical Debt: Why It Actually Matters More Than We Think

When I first heard the phrase “technical debt,” I honestly thought it was just a fancy developer way of saying “bad code.” But after reading Atlassian’s article “Technical Debt: What It Is and How to Manage It,” I realized it’s way deeper than that. The article explains technical debt as the cost of choosing a quick solution now instead of a cleaner, long-term one. This can come from rushing to meet deadlines, adding features without proper planning, skipping tests, or even just writing code before fully understanding the problem. What I liked about this resource is that it breaks the topic down in a way that makes sense, showing how debt doesn’t always come from laziness, sometimes it’s just the reality of working in fast-paced software development.

I picked this article because technical debt is something we’ve basically been talking about throughout CS-348, even if we didn’t always call it that. Whether it’s writing maintainable code, designing clean architecture, or keeping up with version control, everything connects back to avoiding unnecessary debt. I’ve heard instructors and even classmates say, “We’ll fix that later,” and this article made me understand the impact behind that mindset. It stood out to me because it not only defined the problem but walked through how teams can recognize debt early and avoid letting it build up until it becomes overwhelming.

Reading this article made me realize how much technical debt affects the entire development process, not just the code. It slows teams down, creates frustration, and makes simple tasks more complicated than they should be. One part that hit me was how the article described debt snowballing over time. It reminded me of school assignments: if you ignore a confusing part early on, it always comes back to make the whole project harder. Another point I loved was the idea of being honest about debt instead of acting like it doesn’t exist. Communication is a big deal in development, and the article made that very clear.

Moving forward, I’m definitely going to be more intentional about how I write and manage code. Instead of rushing through things just to “get it done,” I want to slow down and think about how my decisions today could affect future work, both for me and for anyone else who touches the code. Good documentation, regular refactoring, testing early, and asking questions when something feels off are all habits I want to bring into my future career. Understanding technical debt helped me see software development as a long game, and being aware of these trade-offs will help me build better, cleaner projects in the future.

Source:

https://www.atlassian.com/agile/software-development/technical-debt

From the blog CS@Worcester – Circuit Star | Tech & Business Insights by Queenstar Kyere Gyamfi and used with permission of the author. All other rights reserved by the author.

Writing Good Documentation

Sources: Ángel Cereijo and GeeksForGeeks

Writing documentation for your project can be tedious and boring. Say you just finished your project, you published it, and you’re excited to see people use it… but they don’t know how. You need documentation to explain your project. 

Software documentation is the writing that goes along with your project, ranging from what your program does, how you plan to build the program, or any notes you may have for your team. There are four types of documentation: requirement, architectural, technical, and end-user. Requirement documentation explains the requirements for the program and how it should perform. Architectural documentation explains how the program should be structured and how processes should work with each other. Technical documentation explains the technical parts of the program, like the API and algorithms. End-user documentation explains how the software works for the user. 

Good documentation should be created throughout the development process. Saving it all until the end will burn you out and set you back. To prevent this, progress the documentation as you build the project. Split your project into smaller pieces, like how it is done in an Agile setting, and improve the documentation as new features are developed. 

Documentation should explain the purpose of the project as well. It should set up a problem that your program solves and why it is useful to solve the problem. Communicate with your team on how the problem is going to be solved and a plan to get there. Then, split the project up into tasks and assign them to the team members. Explain in detail any information needed for each task. Having the research and plan in writing makes it so anyone can complete the task at any time. As tasks are completed, update the documentation to the project before calling it completed. 

Having explanatory documentation also ensures that tests can be written easily, even without the actual code that is being tested. Then, as you write the code for that task, the tests are already completed and you can move on. 

As your team progresses through the project, your initial plan and process will probably change. With new resources and findings, the initial documentation needs to be updated as well. 

Once your project is published, your documentation is there to help the users easily use your program. It needs to be written in simple language for any reader and avoid ambiguity/unneeded repetition. 

Writing documentation is necessary for every project, helping to communicate with your development team and to serve as a guide to the users. It is important to write good documentation and keep in mind how other people will use it. Having the basics down of writing good documentation will help me in the future and give me a step up as a new software developer. 

From the blog ALIDA NORDQUIST by alidanordquist and used with permission of the author. All other rights reserved by the author.

Blog Post for Quarter 4

Considering how the brief simulation of workflow was a recent assignment, I thought it’d be interesting to re-explore the waterfall workflow method. I found this article interesting due to the end. It emphasized potential benefits of aspects of the waterfall method. Instead of outright rejecting it, it highlighted some positives.

I think this is particularly interesting as it highlights the benefits and suggests pulling certain aspects out by suggesting hybrid styles. This also relates back to class by directly referring to agile methodologies. When referring to hybrid styles, they mention combining waterfall and agile together. I found this interesting in how there a likely many different places that use different workflow practices as well. This is also mentioned in the article as it does refer to companies choosing certain styles of workflow.

For example, it used waterfall’s extensive documentation and planning as a positive in some situations. It could be used to keep the agile method in a rough plan and sequence things more effectively. This was described to help maintain a long-term goal more concretely. By stating how the extensive early planning is, it tells of how it may be used in tandem with another style. This can lead to moments where the goal is still clear even if many short-term ones were met. In addition, it can have some flexibility by using agile’s dynamic and constant feedback to make adjustments. This could mitigate the huge commitment of waterfall.

I found this also interesting since I remember concepts of technical debt and clean code as well. Where clean code wants to reduce technical debt by taking more time to make code cleaner and more efficient to modify. I found this interesting in how both waterfall and agile could technically use it. Either by planning on certain things to build from the beginning, or opting for the modularity of relying on numerous functions. Alternatively, documentation could exist to inform on how code should be written, so long term projects are made more consistent. After all, changing too many things may lead to a lot of backtracking, so there has to be a purpose to cleaning up code in a certain way.

This is something that I should keep in mind for the future as I may need to adapt to different workflow styles depending on the company. This is also for personal use to see what flows I prefer in my work. The highlight of pros and cons also tells me I should look out for advantages and disadvantages for other styles as well. It makes things more situational and informs me to be more flexible and open-minded.

https://ones.com/blog/waterfall-lifecycle-computer-science-pros-cons/

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

7 Essential Design Patterns

Design patterns are important for developers to use in their code. They make your programs easy to read and implement and they are able to be adapted to many situations. There are 3 kinds of design patterns: creational, structural, and behavioral. 

Creational patterns are used for creating objects. They give flexibility to change the creation process and allow for many types of objects to be created using the same method. The singleton pattern is used when there should only be one instance of an object. Instead of creating a new object every time you need to call it, you call a method that will call an instance of the object. The builder pattern is used when an object has a lot of optional parameters that make it difficult to know what is being applied when it is created. Using a builder pattern creates an empty or default object and then calls set methods to add each parameter you want to use. The factory pattern is for when there are a lot of objects of a certain type, but with different forms. Instead of creating many new objects, you call a factory to create the objects with the specifications hidden in the factory code. 

Structural patterns are used for how objects relate to each other. These patterns allow for high level code to be readable and simple, while keeping the intricacies hidden below the surface. The facade pattern is used when there are many operations and calculations behind the scenes of a process and those are all hidden with encapsulation. On a high level, one method will, for example, purchase a product, but deeper, there is a payment being processed, shipping calculations, inventory checks, etc. The adapter pattern is for when a program needs to be adapted to fit your code. It can be used for implementing public libraries where their units do not match what your program expects, and each time you use the public library, it calls the adapter to modify the output. 

Behavioral patterns are used for how objects interact with each other. The strategy pattern is used when you have multiple ways of doing a process. Instead of using a lot of if else statements, you can define several strategies and set each object to have a strategy. The observer pattern is used for objects that watch for something. It works by “subscribing” to receive a notification of an event. If a program is watching for errors, it would be automatically notified of any errors so it can add it to a log. 

In class, we went over the strategy, factory, and singleton patterns for the Duck example. These 7 patterns are common practice in the software development field and it’s important to know how to implement them. I watched a video explaining these patterns and now I have a deeper understanding of the three we learned and the four that were new to me. I feel confident I can expand on these in a professional setting.

From the blog ALIDA NORDQUIST by alidanordquist and used with permission of the author. All other rights reserved by the author.

Understanding Software Licensing

Software licensing is a crucial part of the software development process. It is vital to establish a license to set the legal precedent for the work that can be enforced. This blog post from “Click Up” focused on different types of licensing and monetization models.

Software licensing outlines the terms under which a program can be used, shared, modified, or accessed. Different licences can have more restrictions or more freedoms than others.

Types of Licenses from the blog

Propriety: Commercial-based, normally only gives access to use the software and does not allow any further rights. An example is Microsoft Office.

Open Source: Gives large rights for modification, sharing, adaptation, and selling of further forms of software. Some examples are GNU GPL and MIT.

Free and shareware: Freeware can be used for free but may have limited features. Shareware is software that has a free trial version to push the user into buying the full version to either access all the content or continue allowing usage. An example of this is the Adobe suite.

The blog also outlines potential terms of monetization for software and the main forms being used. The types are

Perpetual: One payment with complete ownership of the software. Maintenance may be a separate plan

Subscription: Lower upfront and user-decided cost, but recurring cost with less control and no complete ownership for the user

Usage-Based: Monitor consumption and charge based on usage. Requires metering

Pay-for-overage: User pays base fee and more if they exceed a threshold of usage. Often used in conjunction with usage-based or subscription

Device: Restricts to one or a certain paid for number of paid-for devices

Concurrent/Floating: After paying, you have a set number of uses for the software

I chose this topic due to the coverage in class on licensing topics. While we mainly covered why licensing is important and what the main types are, I wanted to learn more and look into what the other forms of application are. It was good to be able to learn more about how people work to monetize their programs and work through their licenses. One of the biggest things that I learned from the blog and to consider in my future works is in terms of licensing. While I would normally favor open-source for my own projects, in a work environment, I know that the revenue stream from the software must be considered. I now have a greater understanding of potential licenses to consider with software and what the user will be getting when they pay. I found perpetual licenses to be most appealing, and then pushing updated forms to the users or simply selling new yearly versions, as was done in the past with software before switching to a subscription-based model. This is due to my desire to have the user still owning the software while not needing a constant internet connection.

Works Cited:

Team, E. (2024, September 28). Types of Software Licenses and Models Explained | ClickUp. ClickUp. https://clickup.com/blog/types-of-software-licenses/

From the blog CS@Worcester – Dan's Blog by Daniel Fung-A-Fat and used with permission of the author. All other rights reserved by the author.

Quarter-4 Blog Post

For my last quarter blog post, I decided to explore the topic of documentation. Even though we didn’t talk about it directly in class, we were actually working with it during many of our activities, like working with REST, learning how the frontend and backend communicate, and practicing the commands needed to run both sides of a project. Most times the owners of a product aren’t technical, and because of that, engineers end up having to create their own documentation so everyone can understand how things work. All of our in class activities became much easier when we had clear and easy-to-follow documentation in front of us. The blog I chose for this post, written by Mark Dappollone, goes deeper into the topic by giving tips that help both the person building the product and anyone trying to understand how the software works.

Mark’s blog explains three main ideas about documentation that people should understand. The first is that the only way to create good documentation is to just get started and write something. He points out that when there is no documentation, people are forced to rely only on the code and if the code is wrong or changes, no one would know because there’s nothing written down to compare it to. So even if your documentation isn’t perfect, it’s still better than nothing. Without it, clarity disappears and developers end up guessing what’s going on.

The second idea is the importance of using visual aids. One of my favorite examples in the post was when he included a screenshot and labeled each field with the API calls and the data fields they come from. This instantly shows how everything connects to backend data through REST, which is exactly what we practiced in class. With visuals like that, developers can read and understand the logic behind GET or POST requests without having to guess.

The third and final idea is keeping documentation updated. In class, we noticed that even small changes to the code, like changing where data/input is coming from for, can make things confusing very quickly. Without good documentation, things get messy for anyone working on the product. Keeping documentation in sync with changes to both the backend and frontend helps avoid those misunderstandings.

In the future, I can definitely see myself working with API calls or making frontend fixes, and using documentation will help me understand the whole picture. It also ensures that anyone reading the documentation can see how everything ties together. I would especially like to use visual aids because I’m a visual learner, and I think many people are too. Using visuals can help clear up confusion and make the whole development process smoother.

Source: https://mdapp.medium.com/how-to-document-front-end-software-products-e1f5785279bb

From the blog Mike's Byte-sized by mclark141cbd9e67b5 and used with permission of the author. All other rights reserved by the author.

Overview of combinatorial testing

In complex programs, choosing valid test cases often means choosing from many different possible combinations of inputs to find the correct cases. Doing this could take an unnecessarily long time, slowing down the development process, and possibly causing some important cases can be missed. In the article, “Combinatorial testing: What is it, how to perform, and tools”, author Shanika Wickramasinghe explains the details of combinatorial testing, and how it solves the aforementioned problem.

Combinatorial testing involves using multiple combinations of variables for testing, with the goal of this being to verify which/how many inputs of test data, with this information then being used to design future tests. Some of the benefits of combinatorial testing include a larger coverage of possible test cases than normal testing, since multiple inputs are used, reduces the cost and effort of the testing process through the fact that it’s a faster method of testing, and avoiding redundancy, as combinatorial testing ensures that the same cases aren’t tested multiple times.

To better understand how combinatorial testing works, lets take a look at the author’s example. Say we’re trying to test a username and password functionality, and we decide we’re using combinatorial testing for this. Instead of each test case only including one username OR one password, like what would happen if normal testing was being used, each test case includes 1 username and 1 password from a pool of multiple usernames and passwords. For example, let the tested usernames be User1, User2, User3 and let the tested passwords be PW1, PW2. Then, test case 1 could be testing User1 and PW1, then case 2 would test User2, PW1, then case 3 would test User3,PW1, and so on. By doing this, every case would be covered with only 6 test cases, with the same case never being covered twice.

Other types and ways of implementing combinatorial testing are available as well. For example, the example listed above would be an example of manual combinatorial testing, where cases are manually selected from the pools of parameters, where in automated combinatorial testing, software or scripts are used to automate this process and create many test cases automatically. This is especially beneficial if there are many possible inputs, and manually picking each case would be too time consuming.

From the blog CS@Worcester – My first blog by Michael and used with permission of the author. All other rights reserved by the author.

Love and hate relationship between clean code and Writing documentation

The blog explores the paradox faced by developers who prioritize the creation of clean code yet often neglect the critical need for documentation. Despite its essential role in software maintenance and the reduction of technical debt, documentation is frequently undervalued. Studies indicate that well-crafted documentation can substantially enhance productivity by minimizing the time needed for various tasks and improving code quality. A thorough meta-analysis encompassing over 60 academic publications has shown that effective documentation positively influences several aspects of software development.

Although these benefits are evident, developers frequently place greater importance on other responsibilities rather than on documentation, especially when confronted with tight deadlines and a strong focus on producing operational code, a situation frequently encountered in Agile practices. This inclination leads to the creation of informal and outdated documentation, which can exacerbate technical debt. The lack of adequate documentation often results in misunderstandings, mistakes, and redundant work, thereby generating inefficiencies that impede the long-term success of projects.

I chose this blog for its significant relevance to my ongoing studies, as it aids in the practical application of theoretical concepts to my coding endeavors. As a student, I find the article on clean code and documentation to be particularly insightful, as it highlights the often overlooked yet essential role of documentation in software development. While many academic programs emphasize the importance of writing clean code, this article effectively explores the relationship between high-quality documentation and its advantages, such as promoting collaboration, reducing technical debt, and improving overall productivity. Additionally, it offers insights into real-world challenges, including tight deadlines and Agile methodologies, thus preparing students to effectively navigate the complexities of professional environments.

One significant insight from the blog is the importance of documentation in improving collaboration within development teams. Thorough documentation guarantees that knowledge is retained and readily available, which is crucial for team members operating in various time zones or entering projects at different stages. This promotes a more unified working atmosphere, enabling developers to leverage each other’s advancements without unwarranted interruptions. By ensuring that documentation is current and comprehensive, teams can enhance the onboarding experience for new developers and reduce the risks linked to employee turnover.

The blog ultimately emphasizes that clean code and thorough documentation are not opposing elements but rather integral parts of effective software development. By incorporating documentation into the development process, developers can foster the creation of projects that are more sustainable, scalable, and maintainable. This shift in perspective, from considering documentation as a secondary task to acknowledging it as a fundamental component of development, can greatly enhance both the long-term success of projects and the professional development of individuals in the field.

Blog: https://stackoverflow.blog/2024/12/19/developers-hate-documentation-ai-generated-toil-work/

From the blog CS@Worcester – Matchaman10 by tam nguyen and used with permission of the author. All other rights reserved by the author.

Literature in Computer Science

Engaging deeply with academic literature is essential for enhancing one’s comprehension of computer science, as it offers a more profound experience compared to merely watching tutorial videos. While tutorials focus on practical skills and specific tasks, academic papers explore the theoretical underpinnings that inform the discipline’s advancement. The “Papers We Love” initiative, led by Zeeshan Lakhani, Darren Newton, and David Ashby, demonstrates that individuals lacking formal training in computer science can greatly enrich their understanding by studying seminal research papers. This initiative highlights the transformative impact of immersing oneself in academic texts, which often clarify the progression of programming paradigms and foster innovative approaches to problem-solving.

The blog post titled “Papers We Love” presents an overview of four pivotal computer science papers that are strongly recommended for individuals seeking to enhance their comprehension of the field. The selected papers are “Communicating Sequential Processes” authored by Tony Hoare, “Dynamo: Amazon’s Highly Available Key-value Store,” “A Unified Theory of Garbage Collection,” and “Out of the Tar Pit.” Each of these seminal works delves into core principles that have significantly contributed to the evolution of computer science, providing readers with an opportunity to investigate the foundational ideas and progress of essential technologies and methodologies. For example, Hoare’s work on Communicating Sequential Processes (CSP) introduces a formal framework for articulating interaction patterns in concurrent systems, a notion that remains influential in contemporary distributed computing.

I selected this blog for emphasis because I am convinced that the field of computer science encompasses much more than merely consuming tutorial videos. Numerous aspiring programmers become ensnared in what is commonly referred to as “tutorial hell,” where they find themselves perpetually watching instructional videos without attaining a profound understanding of the underlying concepts. This blog promotes the idea of breaking free from that cycle by engaging with scholarly literature, which not only expands one’s intellectual perspective but also offers a solid theoretical framework that is frequently neglected in tutorials. By exploring research papers, programmers can discover invaluable insights that enhance their capacity to develop more efficient, innovative, and elegant solutions to intricate challenges.

Academic publications in the field of computer science often form the foundation for technological advancements. They present innovative algorithms, introduce new frameworks, and analyze complex systems, many of which ultimately become integral to industry standards. While the terminology in these publications may initially appear intimidating, the time spent understanding them is highly beneficial. Developers and researchers who engage with academic literature acquire a competitive advantage, remaining abreast of new developments and enhancing their analytical capabilities to address contemporary challenges. Additionally, this engagement promotes critical thinking and cultivates the intellectual curiosity essential for driving technological progress.

Engaging with academic literature is essential for individuals committed to enhancing their knowledge in the field of computer science. This practice serves to connect theoretical frameworks with practical implementation, thereby promoting a comprehensive grasp of the subject. Regular interaction with seminal works enables programmers and developers to sharpen their technical competencies while establishing themselves as influential figures who can make meaningful contributions to the wider technological community. In a discipline characterized by constant change and innovation, the skill to locate and analyze academic research becomes a vital resource, profoundly influencing both personal career paths and the evolution of the industry at large.

Blog: https://stackoverflow.blog/2022/12/30/you-

From the blog CS@Worcester – Matchaman10 by tam nguyen and used with permission of the author. All other rights reserved by the author.

Clean Code Naming

Almost any young programmer’s first programs look the same. 1. 2. This is all well and good in the beginning, however, non-descriptive variable names pose an issue as time goes on. When your programs get more complex and you work in teams, naming conventions become incredibly important. A lack of naming conventions decreases code clarity […]

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