Introduction

I found an article by Ibrahim Ogunbiyi called Seven Best Practices for Managing Software Licenses. Just based on the title, it seemed to be what I was looking for. It starts off with the basics; what is software license management? According to Ogunbiyi, it’s simply “a document that provides guidelines for the use and distribution of software” (Ogunbiyi). It assists with the controlling, auditing, tracking, and management of a software in an organization and ensures that users comply with the regulations set in place.

Importance

The article discusses the importance of licenses. The reasons include but aren’t limited to:

• Legal compliance with regulations set by organizations/manufacturers
• Keeps track of software due dates; leads to productivity
• Helps manage/reduce costs through enhanced planning
• Optimizes software usage through usage and license tracking data
• Ensures only the use of authorized and secure software, avoiding malware or malicious attacks/breaches

At this point, I think many of those new to software licensing have already taken a huge step forward in their knowledge of the subject. It’s easy to dismiss licensing as something that only grand organizations deal with, but it can be necessary for any small business or individual who wants to protect their work. 

Best Practices

Finally, we reach the best practices as given by Ogunbiyi. In no particular order, these practices are: 

1. Documenting the process of obtaining the software
   1. Who, where, when, how it was purchased
   2. When it is due for renewal
   3. Keep documentation up to date and to certain standards
2. Centralize your list of software licenses
   1. This practice is good for organizations with multiple departments that each have separate licenses
3. Understand the agreements for your software license(s)
   1. Read terms and conditions
4. Use a software license management tool
   1. Assists in tracking, optimizing, and managing software licenses
5. Track license usage regularly
   1. Ensures compliance with rules and regulations
6. Make sure your software license(s) are up to date
   1. Keeps them tracked
   2. Prevents them from expiring
7. Teach employees about managing software licenses
   1. Ensures correct usage of software
   2. Keeps them knowledgeable about the license process and its guidelines

Why This Topic?

I chose this topic because it’s very underappreciated and not mentioned enough in the software development community (from my experience). This could also be useful for an organization or small team that is new to software development.

Conclusion

For me, this article was quite beneficial to my learning. Personally, I previously didn’t know anything about software licensing and the entire process about it. I won’t claim to be an expert on it now, but this article has helped me become a novice in understanding the subject. Although this article didn’t recommend specific licenses, it did teach me the process I should go about when acquiring or dealing with a license. In the future, when I am working on a project either individually or with a team, I’ll be more familiar with the guidelines and process around licensing, and can help my colleagues if they are unfamiliar.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

article link at the end

Overview

This week we began learning about different types of software methodologies, mainly focusing on SCRUM. Scrum, being one of the most popular software development organizational processes, has many factors to consider and to improve on. One of these pieces is the Scrum Meeting, a 15 minute or so meeting with your co-workers and “boss(es)” discussing the day’s work. However, such meetings can easily devolve or change into different forms; certain groups function differently. For example, one team of developers may find it beneficial to have shorter 5-10 minute meetings where there is less communication from each member. Another team may prefer longer meetings with each developer participating in a detailed discussion. But what should it really be about? How should people really be involved? This is where Mike Cohn’s article Daily Scrums: Synchronization Meetings, Not Status Meetings comes in.

What Not To Do

Cohn, a specialist in agile processes and helping companies utilize teams effectively, believes that many companies do Scrum meetings incorrectly. Most current scrum meetings involve each developer giving a report to their scrum master, whilst the other developers sit and wait their turn. Instead, he states that “the daily scrum meeting is designed for team members to synchronize their effort” (Cohn). This opposes the idea of such meetings being used to simply share what one is working on, and move on for the day.

Cohn’s Beliefs

Cohn believes that daily scrum meetings should have members enthusiastic about the project they’re working on with their team along with the progress being made. Such developers should also be sharing their progress and thoughts not only with the scrum master, but with the rest of the team as well. This encourages a broader discussion with more voices and teamwork involved. 

Cohn encourages Scrum Masters to participate in daily meetings, as they can then hear about impediments while also showing support for their team. Lastly, Scrum meetings should have brief updates that focus on what has been accomplished rather than what one spent time on.

Thoughts

I chose this article because it gives a truer, more refined approach to Scrum compared to the ones mentioned. Since I am a beginner to the idea and process of Scrum, I did not know of some of the problems with current iterations of daily scrum meetings. 

This article has been very helpful to me as it introduces what daily scrum meetings should be like. In the past, I had a misunderstanding about how Scrum meetings went; which lined up with what Cohn advised not to do. Although I have not had any real-life experience with Scrum meetings, I feel better prepared as for what to expect in future jobs. I will most likely be using this newfound knowledge in future projects, whether internship or job, big or small. I understand now that it’s best to look forward to scrum meetings as a time to come together and share, and to leave with excitement about progress.

Article: Daily Scrums: Synchronization Meetings, Not Status Meetings

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

Jacob Schmitt’s “Trunk-based vs feature-based development”

Link to article at the end

For this week, I am focusing on Jacob Schmitt’s blog post “Trunk-based vs feature-based development”. This is a short yet efficient article in explaining the differences between the two types of software development processes. Schmitt discusses the alternate use cases of such processes, where and when they might be utilized, who is most likely to use them, and the advantages and disadvantages of them. I chose this blog because as I learn more about forks, feature branches, commits and pull requests, it is important to also understand the overall development processes of companies and why they might use them. The development processes mentioned by the blog intertwine perfectly with git commands and usage.

Trunk-Based Development

According to Schmitt, Trunk-based development allows for developers to push changes straight to the main branch. However, if the new feature will take longer than usual changes, then they can “check out a branch from main, move the changes into it, then merge it back in when the development is complete” (Schmitt). Then, there would be a code review held by other developers to ensure that the new changes do not break the main production branch. Although this development approach is quite popular, it is used more often in the realm of experienced developers rather than newcomers.

Feature-Based Development

As for feature-based development, many developers can work on many different changes or branches at the same time. This is done by each developer creating their own feature branch, and then eventually requesting to merge with the main branch. One of the most important differences between feature and trunk based development is that in feature-based, developers never push straight to the main branch. This approach is much friendlier to beginner developers like myself, as there would be no worry of breaking production with new code since changes are on a different branch.

Advantages & Disadvantages

An advantage that trunk has over feature is that the code changes are more likely to be merged faster. Feature-based development pull requests can add up fast over time, which leads to a longer time between requesting and merging. Despite this, feature-based is much safer for larger development projects and groups, when there are too many feature branches to keep track of at once. As of right now, I prefer feature-based development because I would not be very comfortable working directly with the main branch as a new developer.

Thoughts

Although it might be simple, I found this article to be quite helpful in preparing me for what a future job or internship workflow might look like. When one has little to no experience with development in a professional environment, articles such as this one are very beneficial to learning more about team-based development. It gives a bit more background as to why we do this type of development, rather than just stating that we do it. I hope to use this knowledge in future projects with internships or jobs.

Link to article: Trunk-based vs feature-based development | Jacob Schmitt

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.