Earlier in the semester, we discussed licenses and copyright in regards to our code and documentation. I’ve wanted to write a post on licenses, but finding a post that did more than describe the definitions and uses of licenses was difficult. Luckily, I have found a blog that describes software license management, the best practices, and some drawbacks when managing licenses. From those sections, I want to highlight the parts that felt the most important. The blog is called, “Seven Best Practices for Managing Software Licenses” by Ibrahim Ogunbiyi, a data scientist and IT support specialist.

The post starts off with defining software license management as the process of controlling, tracking, auditing, and managing the use of software in an organization. They highlight the importance of using SLM in many ways, but the one that stood out to me was to ensure the software is secure and has no malicious code. If there is no liability in the rights listed by the license or the lack of one, I can imagine how it would be important to sift through each one to ensure the code is safe to use. Another one that felt important was keeping track of software due dates. Having your team or company rely on access to software only to have it pulled from you could be expensive and time wasting. If you fail to stop after your access is revoked, you could be held liable and sued.

The potential setbacks of SLM were the cost, complexity, and compliance risk. In an organization or large company dealing with a myriad of different license types and potentially using them in combination with each other, I can see how those issues could come up.

The best practices discussed in the post that I found most important were documentation and training. Any issues that arise when dealing with license issues would be incredibly hard to fix if you cannot find relevant information. Keep track of everything, within reason. I have worked in a company that had one person in our location who was fully trained to use the company’s software. She was berated with questions about how it worked without every employee getting a full understanding of the system. She was the linchpin. After she left, so many things fell through the cracks and I can only imagine how detrimental that could be when dealing with licenses. Making sure everyone is on the same page with a full understanding of how licenses work will save companies a lot of time and money.

After reading this post, I felt like this would be especially helpful for people starting their own company. Understanding the complexities and importance of software development can only help in the future. Although I do not feel like I will be making decisions on implementing a software management system anytime soon, I will still keep what I learned in mind when dealing with licenses.

The blog post: https://www.wrangle.io/post/seven-best-practices-for-managing-software-licenses

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

Recently our class discussed inclusive language and delved into tools that are able to root out non-inclusive language. I tried to find an article or blog that gives a set of examples to watch out for. I found a blog post that gives guidelines, examples of non-inclusive language, and provides examples of how companies are adapting to make their language more inclusive. The blog post is called, “Inclusive Language in Technology” by Barathy Rangarajan, DreamWorks Animation.

            The blog post starts with giving a definition of inclusive language. It highlights the difficulty in changing language across repositories and identifying what is seen as non-inclusive language. Before diving into those offensive terms, they give four guidelines when writing code or documentation. These guidelines were: avoid using terms that have social history, avoid using idioms and jargons, write inclusive examples, and if you’re unsure, ask. I personally liked the inclusion of idioms and jargon being something to watch out for and how important it is to ask if you are unsure. Usually, idioms and jargon are just ingrained in the language we use based on where we are. Being aware of that when writing code or documentation for people who may not understand felt important. Understanding that these terms can be tricky to identify as non-inclusive, it’s important to ask those who might know more.

The post then gives a set of terms deemed non-inclusive, organized by different categories. These categories were, socially charged, gendered, ableist, ageist, and violent language.  I won’t get into detail about each, but I recommend you take a look to familiarize yourself with the terms and alternatives. There were some terms I was not aware of.  

The final portion of the article is the how companies have made changes to be more inclusive. They described how Autodesk, DreamWorks, and Sony pictures are addressing non-inclusive language. Some involve hiring based off race and gender, promoting resource groups, and setting a baseline initiative to produce inclusive code in the future and update older code. In one of my previous posts, I talked about setting ground rules that the team can agree on when conducting ourselves during development and discussions. I feel this is also relevant when it comes to inclusive language.

The blog post shed some light on the best practices and popular terms used when addressing inclusive language. In the future I will strive to be self-aware about how I write, ask question when I don’t know, and use what I’ve learned in day-to-day interactions along with writing code.

Link to the blog: https://www.aswf.io/blog/inclusive-language/

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

Similar to my last blog, I wanted to focus on how to implement certain aspects of Scrum in an effective way. While exploring articles related to sprint planning, I came across a crucial aspect not covered in our class, technical debt. The article “How to Run an Effective Sprint Planning Meeting + Tips to Plan Technical Debt Work” by Cate Lawrence, provides strategies for making sprint planning less overwhelming while also highlighting the importance of preventative measures for technical debt. In this blog, I will focus on the technical debt portion of the article. Technical debt is a term used to describe future complications, that are time and resource intensive, that arise from expediting development instead of properly completing the product. It is the tradeoff between immediate gains versus long term consequences.

The article provides three steps for incorporating technical debt into sprint planning. The steps are:

• Make technical debt visible

Recognizing potential issues and highlighting them for the team is important. Letting those issues accrue and not addressing them seemed like the opposite of the Scrum values. You should be adapting to unexpected issues or requests, not planning to have issues in the future.

• Determine the business impact of each debt item

I could see how it may be enticing to take shortcuts during a Sprint. Convincing the team or management to not take these shortcuts and to tackle these issues will only help development, but it may be hard to do. Instead of focusing on all the technical issues in front of them, highlighting how the debt will come calling in the future felt like the appropriate response.

•  Bring it to your sprint planning meeting

After visualizing the issues and showing why it would be best to deal with them now, including them in the next sprint plan is the final step.

Though not the main point of the article, it highlighted that technical debt was a neglected topic in sprint planning. I chose this article due to the steps, but also because it felt like something everyone should add to their Definition of Done. Even if everything “works” correctly with the code, knowing that there could be further problems due to the expedited nature of the sprint, the code should not be seen as done. It should not be ignored and should be addressed immediately or in the next sprint. Hopefully, these steps and the discussion on technical debt in the article will be helpful. In the future, I will try to address these types of issues using the steps, but also incorporate this into the team’s Definition of Done.

Link to the Article: https://stepsize.com/blog/how-to-run-an-effective-sprint-planning-meeting

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

During our classes we discussed the definition, theory, values, team makeup, events, and artifacts of Scrum. I decided to focus on one of the events of Scrum within the Sprint called the Daily Scrum. The Daily Scrum was briefly described and we discussed how the Daily Scrum allows the team to inspect progress toward the Sprint Goal and to adapt the workload as necessary. What we didn’t do was discuss the best way to go about that. I wanted to understand the best practices for proper communication with team members in accordance with Scrum values. The blog “Ten Tips for More Effective Daily Scrums” by Mike Cohn helped with this by giving 10 helpful tips for how to conduct a Daily Scrum. Cohn specializes in agile processes and techniques and makes a living by helping companies build high performance teams.

After reading the tips, I could see that most of the points were prioritizing focus, one of the main values of Scrum. Most of the tips give solutions or show problems that arise that stop the Daily Scrum from focusing on the Sprint Goal. The problems it shows are what I assume to be problems that happen repeatedly for people new to Daily Scrums. They don’t talk about the current Sprint, talk about work done unrelated to the Sprint Goal, focus on unrelated details, and ramble. I liked how the author handled the issues. He pushes the idea that you should set ground rules or guidelines that everyone understands before conducting the Scrum. Having words or phrases that let the team know you might be rambling or for letting a person quickly explain that non-Sprint Goal work was done seemed like a very good way to professionally conduct a meeting. I would think it’s hard to tell someone that they are rambling more than they need to. To have a buzzer or code word established must help communication without hard feelings and allows everyone to be on the same page.

 I also appreciated prioritizing the use of certain words. Saying “impediments” instead of “blockers” or asking about what a person “accomplished” instead of what they “did”. I wouldn’t normally think to prioritize certain words while conducting a meeting, but his explanation on how it changes the team’s perspective on the work during the Sprint was enlightening.

This blog showed me that when communicating with your group, whether in a daily Scrum or not, there are simple ways to optimize communication. The tips given weren’t groundbreaking, but I can see various ways this could be used when communicating with others. Going forward, I plan on setting an outline of ground rules that the team agrees on so we can effectively communicate.

Link to “Ten Tips for More Effective Daily Scrums” by Mike Cohn – https://www.mountaingoatsoftware.com/blog/ten-tips-for-more-effective-daily-scrums#author

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