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.

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.

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 dove into chapter 2 of Apprenticeship Patterns and read the pattern Your First Language. This pattern was about just starting out and only understanding a little bit of one or two programming languages. I thought I would go back to the basics for this week and this pattern would be a good read for that.

The problem this pattern presents is the feeling your job or finding a job depends on your proficiency in a specific programming language. The solution the pattern gives for this problem is to pick a language and become fluent in it. It says whatever language you pick should be your main one for years and will become your default skill you work on when practicing. The pattern mentions the choice is a challenge because it will be the foundation of your early career. Some of the examples the pattern talks about for how you can work on becoming fluent in a programming language is to work on a toy application and write tests for your programs so you can understand what is going on better. A big part of this pattern was finding an experienced coder that you can work with and help mentor you and how it can make the difference in spending minutes on a problem or days. The pattern also mentions the importance of not getting stuck on only using a single language and preventing you from learning a new one.

One of the reasons I chose this pattern is because I can relate to the problem it presents. As a college senior in my last semester finding a job in the software industry will be coming up very soon. I have used several programming languages over my years of school so I have not had to focus on a single language. After reading this pattern I think java should be the language I focus on and become more fluent in because it is the one I know best already. I think I should follow the advice of the chapter and look into working on a small project so I can get better at java. Another thing I would like to do is find a mentor to occasionally help me out. I think that could be very useful for my career. Overall I thought this was a good pattern to read about and it gave me ideas of what I can do to improve my programming skills and create the foundation my career will be built on.

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

This is one of the more interesting patterns in the book. It’s a pattern that discusses the interpersonal relationships between the apprentice the masters or journeymen. I try to portray a lot of enthusiasm when it comes to the workplace. Currently, I work at a sub shop. It’s not my preferred job, but it’s a job, nonetheless. It’s different when comparing this pattern from a software development setting because I feel that I’ve exhausted everything I’ve been able to learn from this job. I try to develop some enthusiasm when it comes down to it though because it’s easier to go through a rush when everyone is in a better mood.

The same thing could be said when it’s time for me to work with a software development team, I can imagine. It’s easy to find people who don’t exactly feel enthusiastic because as the book mentions, they have been working at their job for way too long, they are caught up in many projects and deadlines, and they have no time to stick behind incompetence. After working a couple of jobs, I’ve seen this happen more then I could count, and it’s not a good feeling to conform to everyone else’s mood of dread and pain about a task or subject when feeling the complete opposite.

This pattern can be applied to almost anything in life. The young and incompetent apprentice who feels very enthusiastic about their job is once again shut down by their team. They might feel rather timid in trying to discuss or propose ideas to the team because they are afraid that the team will shut down their enthusiasm. When I’m going through this, I usually began to talk to people I feel that I can express my ideas very clearly too, who won’t attempt to shut them down, or who I feel won’t react negatively toward them. It’s easier to be told wrong by one person than by a bunch of people, and if it ends up being a good idea then I start by telling more people about it until I feel confident that it should be proposed at a more public level.

Sources:

Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly, 2010.

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.