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.