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.

This week I wanted to learn more about concurrency because when I first heard about it I thought that it had to do with money but I found out it has a different meaning than I thought. So what is concurrency and why is it important? Concurrency is the execution of multiple sequences at the same time. This happens when operating systems have multiple threads running in parallel, with the threads running they communicate with each other’s shared memory. Concurrency is the sharing of those resources that cause problems like deadlocks. Concurrency helps with problems like coordinating the execution process and the scheduling for maximizing throughput. There are some ways that allow a concurrency execution, two of them are logical resource sharing which is a shared file and the other is physical resource sharing which is shared from hardware. In concurrency, there are two types of processes executing in the operating systems, that is independent and cooperating processes. The first independent process is a state that isn’t shared with another process, meaning that the end result depends on the input and that it will always be the same for the same input. A cooperating process is the opposite of an independent process, it can be shared with another process and the end result will not be the same for the same input. If you were to terminate the cooperating process it could affect other processes as well. A lot of systems can use at least two types of operations that can be used on process deletion and process creation. For example, process deletion is a parent deleting the execution of one of its children’s classes if the task assigned to the child is no longer needed. A process of creation is when a parent and child class can execute concurrency and share all common resources. Interleaved and overlapped processes are examples of concurrent processes and the relative speed of execution can’t be predicted. Concurrency all depends on the activities of other processes, and the scheduling of operating systems. Concurrency has a better time running multiple applications, a better response time, and a better performance. The sources I used to go more into detail about concurrency and explain the pros and cons of it very well. The reason why I picked this topic is because I thought it was interesting how it enables resources that aren’t used by one application and used for another application instead. It’s also interesting how without concurrency everything would take longer to run to completion because the first application would have to run first before starting another one.

Source:

https://www.geeksforgeeks.org/concurrency-in-operating-system/

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

This week, I wanted to make a post showcasing some examples of documentation for free, open source software. Comprehensive documentation is essential for any software project, so I want to see what useful documentation looks like. I was inspired to make this post when I found myself in need of a new podcast app for my Android device. The one I had been using was no longer refreshing my subscribed podcasts when I opened the app, and I wasn’t able to load the episode lists of any shows. I needed a new podcast app, but I didn’t immediately want to download the Google Podcasts app that was at the top of the search results on their Play Store. I understand Google collects user telemetry and data from their apps, and I didn’t want Google to connect advertising data to my account from the ads many podcasts read from their sponsors. Ideally, I wanted a free and open source app I could use so I could feel more secure in my data privacy.

From Opensource.com, the definition of open source software is “software with source code that anyone can inspect, modify, and enhance.” Many open source projects are supported by communities of volunteers connected over the Internet. The benefits of open source software include stability over time, meaning that because the project can be maintained indefinitely by anyone, the software may remain compatible with modern systems for a longer time than closed source software. Open source software also promotes security for end users. Since the software’s source code is openly accessible, there is a greater chance that undesirable code is deleted or corrected once discovered.

Large-scale projects that require collaboration are supported by extensive documentation for end users. The example I mentioned earlier, AntennaPod, has a simple-to-navigate documentation page that begins with the basic act of subscribing to a podcast, and ends with instructions for podcast creators on how to have their podcast listed on the app through the use of existing podcast dictionaries. One interesting section I found was an explanation of centralized versus distributed podcast apps. Centralized apps are always in communication with a central server, and content is delivered from that server to your device. In contrast, distributed apps send requests to the podcast publishers directly, and do not contact a central server. This approach allows the developers of the app to devote more resources to maintaining and iterating on the app, instead of maintaining a server. Distributed apps are also a protection for user privacy, as there is no interaction with any central server to provide an opportunity to collect user data. The app developers don’t have access to information like which users are subscribed to which shows either. This decentralized, distributed approach also helps protect against censorship, because there are multiple sources to download shows from instead of one central server owned by one entity. Likewise, the app will continue to function even if development ceases, where in contrast a central app will stop functioning if the central server shuts down.

Sources:

• https://opensource.com/resources/what-open-source
• https://antennapod.org/documentation/

From the blog CS@Worcester – Michael's Programming Blog by mikesprogrammingblog and used with permission of the author. All other rights reserved by the author.