In CS-348, I covered many developmental practices and strategies, from the use of  development environments to software design practices. In exploring increment.com I came across an article about the repetitive nature of agile development and how it can lead to burnout and fatigue. The article resonated with me because I will soon be entering the workforce and experiencing agile for the first time. The article’s focus on pausing drew me in to read on. The article’s title is Planning For Pause by Romello Goodman.

The article begins by defining how the agile approach emphasizes speed, flexibility, and continuous iteration by building software incrementally with each sprint. This approach works well for early-stage products but the author points out that the method doesn’t always account for late-stage software. The author identifies that teams can fall into the trap of endlessly adding small, insignificant features rather than working on more meaningful or impactful projects. This leads to a sense of busywork, where the development process feels like it’s stuck in an endless loop of minor updates, creating burnout and dissatisfaction. The author then introduces the concept of milestones, which is defined as an idea borrowed from the waterfall method. These milestones bring structure and pauses into the development process. Unlike agile’s continuous sprint cycle, milestones give teams a moment to stop and reflect on their progress. These breaks allow for a more complete and comprehensive review of the work completed and help realign goals for the next phase of development. The author compares milestones with retrospectives, which can be often overlooked or rescheduled in agile processes. One practical example the author shares is from their team at The New York Times, where they use a two-week cooldown period every six weeks to step back, address technical debt (identified in another blog of mine), and plan future work. By incorporating these breaks into the agile cycle, the author advocates for teams to prevent burnout, improve long-term productivity, and build better software with a pause style. 

I found this article very interesting and pertinent to a big change coming in my life. As I prepare to leave university, I will be experiencing an entirely new mode of software development and teamwork in general. By preparing for the positives and negatives I will have a more complete understanding of how agile works and its potential alternatives. I will continue to read more into the actual development practices I will be actively experiencing.

https://increment.com/planning/milestones-and-agile-development/

From the blog CS@Worcester – WSU CS Blog: Ben Gelineau by Ben Gelineau and used with permission of the author. All other rights reserved by the author.

While studying for my most recent exam in CS-343, I came across a phrase I was familiar with but did not know the meaning of: technical debt. I had a vague understanding and understood refactoring’s purpose to repay technical debt, but I was not positive. I came across an article on increment.com talking about refactoring the definition of technical debt into technical wealth. This article’s title is Reframing Tech Debt by Leemay Nassery

The article discusses the concept of tech debt, which is the accumulation of negative choices made during product development that can hinder long-term system efficiency. The article proposes reframing it as tech wealth. The article begins by explaining that tech debt arises from quick fixes and shortcuts taken to meet product goals. This debt leads to system inefficiencies that accumulate over time. Tech wealth reframes this idea as an investment in building scalable systems that improve developer productivity, system stability, and overall team happiness. A key example comes in the form of an automated deployment system, which makes all development afterwards faster. Tech debt is often seen as a nuisance or a negative aspect of engineering, but through tech wealth you allocate time to improve the code’s architecture. The article argues that addressing tech debt (or building tech wealth) should be prioritized, as it ultimately saves time and resources in the long term. The article gives some example strategies to build tech wealth:
1. Allocate Time in Planning Cycles: Teams should allocate a portion of their engineering capacity to work on tech wealth alongside feature development. For example, 20% of the time can be dedicated to tech wealth activities such as automating processes or improving system architecture.
2. Quarterly Focus: Teams can also dedicate a few cycles per quarter to focus entirely on tech wealth, using this time to clean up past code and improve the system’s foundation.

The article closes with a conclusion that suggests rethinking tech debt as tech wealth and incorporating this mindset into planning cycles. This shift not only benefits engineers but also leads to improved product outcomes for users, even if the benefits aren’t always immediately visible.

This article was essential in my complete understanding of the importance of technical debt. Through this article I was able to conclude strategies to tackle technical debt, and the power to be found in conquering it. I found the automated deployment example most tangible as I have had struggles developing in environments without that feature. Tackling these issues is an interest of mine and I am excited to read more.

https://increment.com/planning/reframing-tech-debt/

From the blog CS@Worcester – WSU CS Blog: Ben Gelineau by Ben Gelineau and used with permission of the author. All other rights reserved by the author.

Throughout the year we have used REST API in class more and more. Through the microservices kit activities I found more interest in the use of REST API. I sought out more information on them to expand my knowledge through an article on REST APIs. The article I found is REST APIs: How They Work and What You Need to Know by Jamie Juviler

The article begins by explaining the importance of REST APIs. They are a widely used framework that allows applications to communicate over the web by following a set of design principles. The article explains it is used to enable data sharing and integrations between systems, allowing software to interact with external services, improving functionality and user experience. The article continues by explaining how they work. By allowing clients to make requests to a server for resources, the server then responds with the current state of the requested resource, usually in a standard format like JSON. The API can also allow clients to modify or add resources on the server. The article explains there are six key principles to know:

1. Client-Server Separation: REST APIs separate the client and server, meaning that the client can interact with the server without needing to know how the server works internally.
2. Uniform Interface: RESTful APIs require a standardized way of interacting, usually through these HTTP methods: GET: Retrieve data. POST: Create new data. DELETE: Delete data. PUT: Update existing data.
3. Stateless: Each request to the server is independent and must contain all the information necessary for the server to fulfill the request.
4. Layered System: In a REST API, there can be intermediary layers (e.g., security layers, load balancers, or caching layers) between the client and the server. These layers should not impact the client-server communication and should be transparent to the client.
5. Cacheable: Responses from the server may be cacheable, meaning that the client can store the data locally and avoid repeated requests for the same resource.
6. Code on Demand (Optional): This optional feature allows servers to send executable code (like JavaScript) to the client, enabling the client to execute this code locally.

The article then explains the benefits of REST APIs, which include flexibility, scalability, interoperability, simplicity, and cost-effectiveness. Juviler then explains how to set up REST APIs with an admin and the article concludes with some examples of the use of REST APIs. 

Rest API has become something very important in class and because of recent assignments I wanted to learn more. Through this blog I understand REST more thoroughly, and the reasons for using it. I understand its feasibility and use for microservices back-end architecture as seen in Thea’s Pantry.

Source:

https://blog.hubspot.com/website/what-is-rest-api

From the blog CS@Worcester – WSU CS Blog: Ben Gelineau by Ben Gelineau and used with permission of the author. All other rights reserved by the author.

After understanding the team aspects of software development, I wanted to shift focus to the tools at a team’s disposal. In conjunction with version control software, development environments become among the most important tools at a tem’s disposal. In projects outside of class I am working closely with docker, and we briefly utilized it to prepare for CS-448 capstone. I wanted to spend more time learning about these development environments. To do so I found an article on the basics of understanding Docker. The article’s title is In-depth Docker by Walter Code

This blog post begins by outlining what it contains. The article expands on configuration management, Docker’s technical components, and Dockerfile commands. Walter explains that configuration management builds on Docker’s layered image management, which addresses issues with traditional “golden image” models that often lead to unmanageable images. Docker’s approach allows for faster iteration and better flexibility. The article continues to highlight some key technical components such as isolation of filesystems, processes, and networks, and resource management via cgroups. Docker is extremely flexible and can run on any x64 host with a modern Linux kernel, and is compatible with OS X and Windows via virtual machines. The post also introduces Docker’s user interfaces, such as Shipyard, Portainer, and Kitematic, which help with container management. Walter also touches on essential Dockerfile commands, like ADD, CMD, and RUN, which are covered to help users configure containers. The article wraps up by discussing Docker’s filesystem layers that allow changes to be applied to a writable layer while keeping underlying read-only layers intact. Additionally, Docker Compose enables users to manage multi-container application stacks, while Docker Swarm helps scale workloads across container clusters. The post finishes by highlighting Docker’s simplicity, security, and rapid deployment, making it a compelling tool for developers, with more practical examples to follow in future posts.

This article helped me better understand how Docker can be essential for teams. It also provided me with more knowledge to aid me in my personal projects that utilize docker. This is a key step for me in understanding how best to work with a team with these tools. What I found most helpful was an explanation of how Docker’s configuration management could be used, and why docker compose is so useful. Next in my blog I will cover more strategies or tools to help me better function in a team for software development. 

Source:https://waltercode.medium.com/in-depth-docker-faa0c4dd9a63

From the blog CS@Worcester – WSU CS Blog: Ben Gelineau by Ben Gelineau and used with permission of the author. All other rights reserved by the author.

As my year progressed I wanted to better understand the basic principles of software design and sought out the SOLID principles after hearing about them throughout college. I had not yet put the time into properly learning and practicing them and came across a blog putting the principles into text simply and with excellent examples. The article’s title is The SOLID Principles of Object-Oriented Programming Explained in Plain English By Yiğit Kemal Erinç

The article begins by identifying what the SOLID principles are and their importance. These principles are five key guidelines for object-oriented design that help developers create maintainable, flexible, and understandable code. These principles are provided in great detail, with several coding examples and potential drawbacks or dangerous pitfalls. They are the:

1. Single Responsibility Principle (SRP): A class should have one responsibility and one reason to change. By adhering to the SRP, you minimize complexity, avoid conflicting changes, and simplify version control and collaboration.
2. Open-Closed Principle (OCP): Classes should be open for extension but closed for modification. This means new functionality can be added without altering existing code. This is often done by using interfaces or abstract classes. 
3. Liskov Substitution Principle (LSP): Subtypes must be substitutable for their base types without altering the correctness of the program. 
4. Interface Segregation Principle (ISP): Clients should not be forced to depend on interfaces they don’t use. This principle advocates for creating small, specific interfaces rather than large, general-purpose ones. It ensures that classes only implement methods relevant to their functionality, and there is less bloat and redundancy in the code.
5. Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules, but both should depend on abstractions. This means This promotes flexibility and low coupling, making systems easier to extend and modify.

The key takeaway presented in the conclusion is that by following SOLID principles, developers can write cleaner, more testable, and scalable code.

The SOLID principles are essential and key learning blocks for building efficient code. This is a topic that has been addressed in class as design smells and patterns. By learning this through the lens of SOLID I was able to reconcile the importance of that topic in building good code. Through the CS-343 course, I was looking to understand those design patterns better, and by understanding them as SOLID principles I am able to better grasp them. I will be prepared to answer questions regarding SOLID principles in context thanks to this article in combination with the class material.

Source:https://www.freecodecamp.org/news/solid-principles-explained-in-plain-english/

From the blog CS@Worcester – WSU CS Blog: Ben Gelineau by Ben Gelineau and used with permission of the author. All other rights reserved by the author.