Understanding software licensing is one of the crucial, non-coding topics that becomes a massive deal the moment you start building real applications. When covering this in my Software Process Management course, I was overwhelmed by the density and intimidation of the numerous license types and legal details. For this blog post, I decided to use this opportunity to strengthen my understanding of these various software licenses. This information is vital for my plans, especially when creating high-integrity therapeutic platforms where security and protecting ideas are non-negotiable. To achieve this goal, I looked at several resources to deepen my understanding.

To make sense of licensing, the best first step is grouping them into two major categories: Proprietary (Closed source) and Open Source. As the resource by Zluri, “3 Major Types of Software Licenses & Its Categories” states, proprietary licenses are the most restrictive type as their whole purpose is to keep the source/base code private. This means, you can only use the software via permission and under strict conditions; you will not be able to edit or distribute the code yourself. For my work, this proprietary model might be necessary to protect the specific clinical methodology or algorithms I develop for future therapeutic platforms. Open source licenses, on the other hand, make the source code publicly available, which is the best for those who are looking for collaboration and efficiency.

However, this resource by BlackDuck states, open source licenses can become overwhelming. To best understand, I grouped the following licenses from easiest to more difficult to handle. Permissive Licenses (i.e., MIT and Apache 2.0) are the easiest to use as they are very flexible and only require you to include the original copyright notice. Copyleft licenses (i.e., GPL) have a strict rule to follow. That is, if you distribute a modified version of software, you must also make your modified source code available under the same copyleft license. If I used a copyleft feature in a therapeutic game, for example, I would be forced to release the source code of my entire game; which is a major factor protecting the core methodology and design. 

Licensing is more about just reading and considering rules, strategic planning is very important with choosing which to work with. It directly impacts ethics, decisions, and compliance of any platform handling sensitive information. If I am to build things like interactive feedback systems or symptom management trackers, I need to know exactly which third-party tools I can safely use. My current task is figuring out that delicate balance to ensure I build professional, compliant, and sustainable software that protects both users and the core therapeutic intervention.  

Main Resources:
3 Major Types of Software Licenses & Its Categories – https://www.zluri.com/blog/types-of-software-licenses

Five types of software licenses you need to understand – https://www.blackduck.com/blog/5-types-of-software-licenses-you-need-to-understand.html

Additional Resources:
Software Licensing Models: Your Complete Guide – https://www.revenera.com/blog/software-monetization/software-licensing-models-types/

Software License Types, Examples, Management, & More Explained – https://finquery.com/blog/software-licenses-explained-examples-management/

From the blog CS@Worcester – Vision Create Innovate by Elizabeth Baker and used with permission of the author. All other rights reserved by the author.

For this quarter’s blog post, I decided to speak more about the principles of clean code. The resources I discovered when exploring this topic surprised me. I have understood the general concept of writing code that is easy to read, maintain, and understand from the start of my time here at Worcester State University. However, now I have been introduced to the more specific and controversial perspective explained by Robert C. Martin (aka, Uncle Bob). My goal with the resources I chose was to compare Uncle Bob’s approach against how clean code is viewed in more general practices.  

This resource, Clean Code: The Good, the Bad and the Ugly, explores Uncle Bob’s perspective on clean code, while the author identifies components they see to be good, bad, and ugly. The resource “Clean” Code, Horrible Performance, tests Uncle Bob’s clean code components and explains how it impacts performance. Lastly, there are two other resources that give examples of general practices of clean code.

From what I understand, the core idea of clean code is that people read code way more often than they write it, so it is important to prioritize clarity. However, on the other hand, Uncle Bob’s perspective advises for small functions and almost no comments. Some of Uncle Bob’s advice is similar to general clean code practices, but this specific advice leads to some conflicts.

The first two resources showed that sticking too closely to Uncle Bob’s principles can actually lead to decreased performance. This happens due to highly fragmented code (following his principles on small, single-purpose functions), which can be less efficient for the machine to run. The main takeaway from these conflicting views is that Uncle Bob’s ideas are helpful guidelines, but they are not universal rules. It is important to understand the trade-off between absolute readability and optimal performance based on the focus and needs of the project you are working on. 

The advice against using comments genuinely surprised me. In one way, comments are a great way for beginner coders to track the purpose of their code, and to boost their understanding of certain components (i.e., loops, methods, functions, classes, etc.). At least, that is what I often used comments for when practicing coding alone. Now I understand that, when working on a team, those initial comments can quickly become confusing and unhelpful. If a comment is not deleted or updated when the code changes, it becomes misleading. Your code should describe itself using good variables, functions, and method names. If you need a comment to explain what each part of the code does, that may be a sign of poor coding design. 

I had intended to use clean code as I continue practicing coding. However, now I have more tools under my belt to make sure my code is not just digestible for me, but also digestible to someone who may need to read or update my code without me there to explain it.

Main Resources:
“Clean” Code, Horrible Performance. Many programming “best practices” taught today are performance disasters waiting to happen – https://www.computerenhance.com/p/clean-code-horrible-performance

Clean Code: The Good, the Bad and the Ugly – https://gerlacdt.github.io/blog/posts/clean_code/

Messy Code V/S Clean Code in MVC context – https://medium.com/highape-tech/messy-code-v-s-clean-code-in-mvc-context-9ad99079a4f8

What Is Clean Code? A Guide to Principles and Best Practices – https://blog.codacy.com/what-is-clean-code

Additional Resources:
Polymorphism in Java – https://www.geeksforgeeks.org/java/polymorphism-in-java/

From the blog CS@Worcester – Vision Create Innovate by Elizabeth Baker and used with permission of the author. All other rights reserved by the author.

For this quarter’s blog post, I further explored the importance of developing a strong software team. The resource I chose is an article called “Better Software Engineering teams — Structures, roles, responsibilities and comparison with common approaches.” I chose this resource because it offers insights into how groups are organized for success, as well as the drawbacks of specific approaches that are used in current day. Building strong software development teams is a topic that ties directly into my current course, Software Process Management, discussions on team structures and project methodologies.

This article identifies and describes core characteristics of high-performing software engineering teams. It stresses the importance of traits like clearly defined roles, balanced seniority, responsibility and ownership, reasonable size teams, trust, transparency, strong leadership for effective team cohesion, executing and developing skills, to build and maintain a team environment of honesty and shared responsibility. 

This article strongly emphasizes the importance of having small and manageable sized teams, and provides a visual to better understand how bigger teams equal to higher chances of miscommunication and reduced efficiency.

Two common flawed approaches are analyzed (Single-Discipline Teams and Manager-Led Cross-Functional Teams) and compared to the optimal approach: Self-Managed Cross-Functional Team, via strong pros and cons lists. The key takeaway of this is to express that when team members understand their contributions to company and project goals, they are better equipped (with hard and soft-skills) to organize themselves and produce results efficiently.

This resource also reiterates the importance of team structure and team size, something of which I am directly experiencing within my POGIL-approach class, and class discussions on Agile and Scrum methodologies. This article provides the professional, industry-level validation for this very concept: the benefits of small, cross-functional groups for project completion.

My takeaway from this article is the benefits of self-managed cross-functional teams, and how unbalanced teams can lead to an increase of overworked members, lack of team cohesion, and decreased value and motivation into the project development and goal. Group work can be challenging, and even more so when the core values of a functional and strong team are absent. The article also emphasized the importance of strong leadership, as poor and ineffective leadership can be the root cause of common issues like “quiet quitting,” where team members feel the only way to bring attention to the poor leadership environment. This challenge is present, much too common, in fields outside of software development teams. 

As someone who sometimes struggles in team settings, due to worries about offering incorrect and simple input, I will make sure to understand the value I contribute to the team and not steer from contributing my knowledge. Even if my contributions are “simple” or “incorrect”, this will provide an opportunity to connect with and learn from my teammates, build an environment of trust and open communication, and strengthen my own leadership skills. As leadership does not start and end with the managers/leads of the team.

Main Resource:
https://medium.com/geekculture/better-software-engineering-teams-structures-roles-responsibilities-and-comparison-with-common-fb5c3161c13d – Better Software Engineering teams — Structures, roles, responsibilities and comparison with common approaches.

Additional Resources:
https://www.inc.com/peter-economy/why-quiet-quitting-is-actually-a-leadership-failure-and-how-to-fix-it/91181524 – Why Quiet Quitting Is Actually a Leadership Failure — and How to Fix It. Quiet quitting is a virus that affects entire organizations. Where it stems from might surprise you.

From the blog CS@Worcester – Vision Create Innovate by Elizabeth Baker and used with permission of the author. All other rights reserved by the author.

For this quarter’s blog post, I chose to deepen my understanding of Version Control systems (VCS), specifically how tools like Git and platforms like GitHub and GitLab function within the software development lifecycle. Learning new tools and techniques takes continued practice, and learning Git was no different. My goal with this content is to strengthen my knowledge of the core concepts and purpose behind these vital tools, which is what my Software Process Management course is currently emphasizing working with and practicing.

I focused on a website from GitHub itself, which explained what version control is. I chose this resource because it provides a foundational explanation of VCS, its types, and current popular tools. This article, “What is Version Control?”, defines VCS as systems that give members working on the same project complete visibility into the history of the code, and centralize all members’ work. It describes how Distributed Version Control Systems (DVCS), like Git, are essential for software development. It explains key concepts including the ability to track every change, work independently, propose code additions, and safely integrate changes while preventing conflicts. In other words, the process of commits, branching, pull requests, and merging; all fundamental processes we are focusing on in my course.

Before this course, and diving into resources, my understanding of Git was minimal. I gained a much deeper grasp of how VCS tools are both seen as a safety net and a coordination tool. Branching is one of the most important steps within the software development process, as it allows a team (of however many or little) to work synchronously on a project without fear of overwriting or corrupting the main code. Allowing team members to work independently, cohesively, and in a time-efficient manner; while also being able to access and review modifications made by other members via accessing their branch of the project. 

Although all of the information is important, the section on best practices particularly resonated with me. While working with Git, we are encouraged to save changes in small increments, making sure to write a helpful commit message, rather than making large changes and saving at the end. Seeing this best practice emphasized in the article reinforced its importance. Using this technique significantly reduces conflicts and makes debugging errors and explaining changes much simpler. 

I expect that I will continue using Git throughout my professional career, and I plan to apply this understanding immediately as I continue working with Git in class. My goal is to use this knowledge and helpful techniques to practice improving my execution and workflow. I will prioritize working in small increments, committing those small changes, and reviewing my changes to ensure my progress is meeting expectations and to also contribute to the team’s collaboration.

Link to Main Resource:
– https://github.com/resources/articles/software-development/what-is-version-control – What is Version Control?

Link to Additional Resources:
– https://www.cbh.com/insights/articles/collaboration-tools-changing-the-workplace-landscape/ – Collaboration Tools Changing the Landscape of the Workplace

– https://www.planview.com/resources/articles/software-development-collaboration-tools-a-detailed-buyers-guide/ – Software Development Collaboration Tools: A Buyer’s Guide for Empowering Agile Teams

– https://fullscale.io/blog/benefits-collaborative-software-development/ – The Benefits of Collaborative Software Development

– https://www.geeksforgeeks.org/git/version-control-systems/# – Version Control Systems

– https://www.geeksforgeeks.org/git/what-is-git/ – What is Git?

– https://github.com/resources/articles/software-development/what-is-software-development – What is Software Development?

From the blog CS@Worcester – Vision Create Innovate by Elizabeth Baker and used with permission of the author. All other rights reserved by the author.