The article I chose for this week’s blog post is “A PRIMER ON OPEN SOURCE LICENSE COMPLIANCE” by Dasha Gurova. This article discusses what Open Source Licensing is, what software licenses are, why you should implement an open source license compliance policy, some examples of semi-automated OSS compliance tools, and how to use OSS (open source software) compliance systems. I will be discussing the ways of implementing OSS compliance systems mentioned in the article, those being the manual and semi-automatic methods, and their strengths and weaknesses.

The methods the article mentions for maintaining OSS compliance are manual and semi-automatic. The manual process is a very time-intensive approach and an old-school approach. “A surprising number of companies are still using this approach. Basically, you create a spreadsheet and manually fill it out with components, versions, and licenses and analyze it against your policy.” The article also says that this method can be very effective on smaller projects if implemented early in the project’s development. This method would entail reviewing and logging the software’s license before implementing any components from the open-source software. However, if not implemented early, using this method can be very difficult to execute properly. This method also becomes much more challenging to maintain as your project uses more and more OSS components. Especially to make sure the licenses that you are using do not conflict with one another and are being adequately implemented. These issues can be made worse especially when this method is not being maintained properly, in addition to being used in a large project.

The other method mentioned in the article is the semi-automatic method. “This is a more reliable approach and is becoming more popular, as the importance of open source compliance practices grows along with the risks associated with ignoring these practices. There are many tools available, in a way that it gets overwhelming. Why semi-automated? Because there are always false positives if the license is not explicitly referenced in the header and you still have to read through some of them to discover special terms or conditions.” As mentioned in the article, this method is far more reliable but teams that use this method must be vigilant to see if the warnings that the tools give are false positives. If the team using this system just assumes all the warnings are completely accurate this could lead to a lot of headache trying to find other OSS that would comply even though you already had OSS that would work.

Article: https://www.zenko.io/blog/get-started-with-open-source-license-compliance/

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

In this week’s blog post, I will be discussing some of what I learned about the DRY design principle from the article “The DRY Principle: Benefits and Costs with Examples” written by The Valuable Dev. I initially chose this particular article because it perfectly aligns with the DRY design principle topic within the syllabus. This article discusses what DRY is, as well as why you shouldn’t always use DRY. I personally found the author’s use of humor to be very refreshing. I feel many of the blogs I have read so far have seemed to be robotic in how they are written.

The article says that DRY is primarily about a repetition of knowledge first and foremost. “Therefore, the logic of this shipment should only appear once in the application. Why? Imagine that you need to send shipments to a warehouse. You need to trigger this behavior in 76 different places in your application. No problem: you repeat the logic 76 times. After a while, your boss comes to you and asks you to change this behavior. Instead of sending shipments to one warehouse, you need to send them to three different ones. The result? You’ll spend a lot of time on your shipment logic since you’ll have to change it in 76 different places! This is a waste of time and a good way to produce bugs to piss your boss off.” The author suggests instead of repeating the logic that you are using, and it would be better to use abstraction to prevent the kind of issues that the example given causes. This would not only allow for changes to be made faster but also minimize the risk of bugs being created because you are only changing code in one area instead of 76 different places.

The author also discusses a situation where DRY doesn’t apply. In this example, the author is working on software for a VOD (video on demand) platform that both filmmakers and content teams would use regularly. The author was considering creating abstract classes to use instead of the current implementation that was being used due to many classes being almost copy-pasted, as well as seemingly having similar utility for both filmmakers and content teams. “In many cases, we knew that the interface would evolve differently in the future. We would have created a lot of conditionals in the controllers’ actions if we had created one set of controllers for both applications. Nobody wants a forest of if statements; the resulting code would have been way more complex. Additionally, the controllers shouldn’t contain any business logic. If you recall the definition of the DRY principle, it’s this knowledge and business logic that should not be duplicated.” As both classes would become more developed in the future, they would differ significantly. If they were made into an abstraction, the code needed for them to work for filmmakers and content creators would have been messy and complicated to manage.

Article: https://thevaluable.dev/dry-principle-cost-benefit-example/

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

For this week’s blog post, I chose the article “Code Documentation: How to Do It Right” by the editorial team of SkillReactor. I chose this article in particular because it aligns well with the code documentation section of the syllabus. This article goes into great depth about code documentation and its benefits, as well as how it is best implemented. In this blog post, I will specifically be going over the code documentation tools discussed in the article and how the article discusses overcoming documentation challenges. Prior to reading this article, I wasn’t very familiar with code documentation tools, but I learned much about their function and how some of the tools mentioned can be used with multiple programming languages.

The article mentions a few specific code documentation tools that are commonly used in software development. One of the tools mentioned that caught my attention is Doxygen. “Doxygen is a versatile tool that supports multiple programming languages and generates documentation in HTML, LaTeX, and RTF formats.” Doxygen is very interesting because of its benefit of functioning alongside multiple programming languages and creating documentation in HTML, which, in my experience, can be very difficult to navigate without some form of documentation guiding you. I also found Sphinx to be fascinating because the article mentions that it makes use of automated API documentation generation. “Sphinx, primarily used for Python codebases, offers automated API documentation generation and support for reStructuredText markup language.” This tool having the capability to generate documentation for your code automatically can be immensely helpful; it being automatically generated can also help with accidentally using jargon or slang that may not be understood by others reading through your code. Another essential aspect that the article discusses is overcoming some challenges associated with creating code documentation.

Writing documentation into your code comes with great benefits, but often, it can be difficult to implement into your project. One of these challenges being maintaining up to date documentation with a project. “Although code documentation offers numerous advantages, it comes with its own set of challenges. Managing updates to documentation can be a daunting task, particularly in large projects where multiple developers are working simultaneously.” Another challenge that comes along with creating documentation is avoiding redundancy. “Another challenge is avoiding redundancy in documentation. When multiple code sections use the same functions or variables, it can be tempting to copy and paste documentation, resulting in redundant documentation and confusing code.” However, these challenges can be overcome with enough diligence. “To overcome these challenges, it is essential to establish specific standards for documentation management and to incorporate documentation review processes into the development workflow.” As long as these standards can be maintained and code documentation is regularly reviewed, the documentation implemented with your projects should be of high quality and make understanding your projects much easier for your fellow developers.

Article: https://www.skillreactor.io/blog/the-importance-of-code-documentation-and-how-to-do-it-right/

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

The article I chose for this week’s blog post is “What Is an Anti-Pattern?” by Andreas Schöngruber. I chose this article because it discusses what anti-patterns are, gives some examples of anti-patterns, and how to avoid them. I chose this article for this week’s blog because it fits well with the syllabus topic of anti-patterns. I found the section about recognizing and avoiding anti-patterns to be very helpful. This blog post will focus on the aforementioned section about recognizing and avoiding anti-patterns in your code.

I will first discuss the section of the article which discusses recognizing anti-patterns in your code. One method that the article mentions involves keeping an open mind and looking to others for feedback. “When identifying anti-patterns in our code or design, we must keep an open mind and question our assumptions. Sometimes, we may become attached to a solution that required a lot of time and effort, but there might be a better solution out there. To avoid this, it is helpful to seek feedback from others.” As this quote states, it is imperative not to be too attached to a process that you developed or are developing, especially if the time it takes to develop or implement this feature is more than the value that the feature is worth. Another important part of being able to mitigate the harm done by anti-patterns is knowing how to avoid them.

While being able to identify anti-patterns is incredibly important, it is also important that one knows how to prevent their occurrence in the first place. One method of doing so is by stepping back and looking at the greater picture of the project that you are working on. “When working on software projects, it is essential to be aware of common pitfalls that can lead to anti-patterns. One strategy to avoid these pitfalls is to take a step back and consider the larger context of the problem. Understanding the problem in its entirety will help in coming up with a good solution.” Instead of being hyper-focused on one part of a larger project, which could lead to anti-patterns arising in your code, its best to take a step back occasionally to make sure what you are working on is not falling into the traps of anti-patterns. Another method of preventing anti-patterns would be a divide-and-conquer approach to developing features. “Another strategy is to break down large problems into smaller pieces. Doing this can help avoid getting overwhelmed and make it easier to spot issues and inefficiencies.” Using this strategy can be very beneficial because it can allow you to see anti-patterns as they appear in your code.

Article: https://www.baeldung.com/cs/anti-patterns

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

The article I chose for this week’s blog post is “Understanding Software Process Models: What They Are and How They Work” from the Institute of Data. I chose this article because it fits well with the software process models section of the course topics in the syllabus and can help solidify an understanding of this topic. I was also surprised to learn that software process models are very dynamic. Before reading the article, I thought they were a rigid but vague system of how to develop any project. The article mentions that each system process model is tailored around the current project being developed. The parts of this article I will be discussing are defining process models, the role of software process models in software development, and the critical components of software models.

The first section of the article I will discuss is defining software process models. The article defines software process models as “…frameworks that define the sequence of activities, tasks, and deliverables required to develop high-quality software.” The article says that software process development models act as a roadmap, providing steps that help guide a software development team and are also a dynamic way of structuring a project development. The article also discusses the role that software process models have in development.

Software process models are essential for development teams to work alongside one another. The article discusses in depth how important software process models are for development. “Process models play a crucial role in ensuring that projects are executed smoothly in software development. They provide all team members with a common language and understanding, promoting effective collaboration and communication.” As stated in the article, software process models allow colleagues to have a common understanding of how and what needs to be implemented and when. This allows for significant clarity and helps discover potential issues early in development. The article also mentions how using system process models can help with costs. “By clearly understanding the activities and tasks involved in each phase of the development process, teams can estimate the time and resources required more accurately. This helps in setting realistic project timelines and budgets.” This is one of the most important benefits of using software process models during development, saving developers time and money and resulting in shorter development cycles. The article also discusses some key components of software process models.

The article mentions some key components of software process models. I will just be going over requirements gathering and analysis for the sake of brevity. “Requirements gathering and analysis is the first phase of the software development process. It involves understanding and translating the client’s needs into clear and concise requirements.” This part sets the groundwork for the project and helps ensure the end product matches the client’s vision. If this part of the software development process is not completed correctly, your end result will likely not be what the client wanted, which means that this first part of the process is one of the most important parts of the entire process.

Article: https://www.institutedata.com/us/blog/understand-software-process-models/

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

The article I chose for this week’s blog post is: “YAGNI (You Aren’t Gonna Need It) Principle Helps Devs Stay Efficient”, by Tatum Hunter. The article discusses what YAGNI is, how implementing it is difficult but necessary to implement in development teams, how it can be hard to know when to use YAGNI and how YAGNI can be applied to business as well as using a YAGNI methodology in making contracts. In this blog post I will be focusing on how being able to say no or not yet to a customer or employer is vital to a YAGNI system of software development. I chose this because we learned in class how useful YAGNI is to software development, with how it helps save time and money, as well as help morale and how communicating with customers or employers about what might not be good to implement is important.

YAGNI can be an incredible tool for making sure your team isn’t wasting time and energy on code that will not be used in the final product. This is incredibly useful, because as stated in the article, working on something for months thinking its going to be a great success just for it to be thrown aside can be devastating for team morale. “‘After months of hard work, it [a new component management system] just went by the wayside,’ she told Built In in 2020. ‘It might have been the right business decision at the time, but the team’s morale was really impacted.’” When YAGNI is implemented properly, it should lead to a faster development cycle meaning this project could have been completed before it was put aside. Saving the company money, and the team a lot of heartache.

Learning how to communicate YAGNI with customers and employers is one of the most important parts of implementing YAGNI especially if a requested feature may not be necessary. “‘To do that, we had to say ‘no’ or ‘not yet’ to about 30 features,’ Dingess said. And, true to YAGNI, that was the right call. After the product launched and the team could collect real user feedback, those 30 features ended up being irrelevant anyway. Instead, the team pivoted to build out the product based on that feedback.” A customer may want you to work on many extra features alongside your main task, only to later realize that many of those extra requests were not needed. If you were able to communicate to the customer that it would be best to implement those features at a later point in development, you would have saved a lot of time and effort for yourself, and money for your customer.

What I found to be most interesting about the article is how it relates the YAGNI principles to working with customers to make sure development teams don’t waste time and effort on implementations that don’t end up being used, or whole projects being scrapped all together.

Link to the article: https://builtin.com/software-engineering-perspectives/yagni

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.