Quick recap of the first post, Miriam Posner saw an Agile team working and as an outsider decided to research more about the process. The article started with the defining of programmers as software engineers, an attempt to add structure to the confusing new field. From there was the “waterfall” development process, a term coined as a joke that was picked up by the management and used until the inflexible nature nature caused one too many projects headaches. A new movement was made by 17 managers who wrote the “Agile Manifesto” in February 2001.

Picking up from there Miriam goes into a little more detail on “waterfall” shortcomings as developers see it, the largest of which appears to be that any slowdown was seen as a ‘deviation from management’s careful plan’ because software development was inherently stable, at least from management’s pov. Agile was supposed to be about removing long-term, higher level plans set in stone in favor of short-term, quick-paced goals that would give more flexibility for developers. Remove useless meetings about every little thing so developers can actually fix the problems at hand. Miriam notes that at this time there were few qualified devs, so they had all the power and could have asked for unions or complete IP ownership. Instead they asked for more efficient working conditions so they could do their jobs.

While this sentiment from coders culminated in the 2001 manifesto, according to the Agile consultants Planview it took until 2012-2015 for more than 50% of active development teams to characterize themselves as “Agile”. So that was it right, new mindset and all’s hunky-dory. Except it wasn’t.

In a cruel twist of fate, Miriam noticed a flaw in that Agile team that she had been watching be so efficient and intriguing. They didn’t seem to be getting much work done. What had happened was that due to throwing out the top-down approach to project management, no one on the coder’s side had a solid concept of the project in its completed form. They had thrown out the baby with the bath water. Add on to the fact that, while definitely anti-management Agile was in a way very pro-corporate. The entire mindset was let developers put their all into the project, which in turn is believed to have contributed to the recently seen burnout rate increases. On top of this is the issue that, due to Agile’s inherently non-structured nature as a mindset, there’s no one thing someone can point to to say “this is not good we need to change it.” Since nothing is actually defined in Agile, everything is subjective and thus at the whim of whatever the company decides.

From this article I have come to see that flexibility in my future work is necessary, don’t try to plan every part from day one. However it is equally important to try to start with a skeleton, something that I can add my features to so that I know both where my projects are at as well as what it can become. Hopefully this adjusted mindset will allow me to continue doing what I love for a long, long time.

Link:
https://logicmag.io/clouds/agile-and-the-long-crisis-of-software/

From the blog CS@Worcester – Coder's First Steps by amoulton2 and used with permission of the author. All other rights reserved by the author.

Integrated Development Environment, commonly shorten as IDE, is something that exists among the modern Development Environment today. Imagine the common text editors software such as Notepad on Windows, or TextEdit on Mac, we can theoretically write the code and save it as the correct extension file, such as *.py, *.java, etc.. However, this requires us to learn every syntax of the code, as well as time consuming in terms of managing the working directory in the project. Therefore, the blog article “Understanding Modern Development Environments: A Complete Guide” by Matthew LeRay, will help us how to easily manage the development environment process in terms of the versatility.

In summary, the blog article gives us the basic introduction surrounding the definition of Development Environment. It is about comprehensive setup of hardware and software tools that software developers use to create and maintain software systems, along with other elements such as Developing, Testing, Staging, and Production Environments. The article highlights how IDE compared to traditional text editors process, which what we know today are syntax highlighting and code completion, and more highlights on the point of time consuming, enhancement of developer proficiency, and customization tools. And lastly, the article highlights the importance of development environment, where the goal is for enhancing developer productivity and ensuring high-quality software output.

I choose this blog article personally due to my own curiosity of “What if I try using a text editor software on my computer to write code?” The article did give a basic introduction in terms of the long evolution where IDE is formed from the traditional use of Text Editors. Reflecting on what I’ve learned using VS Code, it is not just basic functionality such as code completion and syntax highlighting, the versatility of IDE expands to the advanced features, such as integrated version control, and collaboration tools, in order to catch up with time management process as the complexity of the project grows over time. Overall, this blog article helps me learn that I can’t simply just rely on the text editors software, such as Notepad or TextEdit, as mentioned from the introduction of this blog post. And the reasons for why not can be seen as I started to get touch on the higher complicated project, where using an IDE such as VS Code would reduce the time process, as well as further advantages such as working with collaborations team, compared to solo development.

In my opinion, it’s easy get familiar with advanced, and modern Development Environments, where I think collaboration and time management could reduce the complexity of managing the project in the real world. Hence, trying to setup the crucial elements such as the right IDE, Version Control System, can be the good start when working with the modern Development Environment, to expand my versatility when working on with necessary tools to enhance the development proficiency, and for the overall production enhancement.

Blog Article: https://speedscale.com/blog/modern-development-environments/

From the blog CS@Worcester – Hello from Kiet by Kiet Vuong and used with permission of the author. All other rights reserved by the author.

This week, the blog that caught my attention was “How to Make Your Development Environment More Reliable” by Shlomi Ratsabbi and David Gang from the Lightricks Tech Blog. This work highlights common challenges encountered in software development and provides actionable solutions — specifically, how to optimize development environments. The insights offered in this blog align perfectly with our coursework, as we have continuously learned about and worked within our own development environments. This post emphasizes the importance of ensuring consistency and reliability when creating these environments, offering practical advice to achieve this goal.

The writers begin by outlining the necessity of development environments, describing the challenges that arise during software releases. These challenges include discrepancies between local and production configurations, mismatched data, permission conflicts, and system interaction issues. While creating a shared development environment may seem like the obvious solution, the authors point out that this approach introduces its own set of problems, such as debugging difficulties due to parallel testing, interruptions caused by developer collisions, and divergence between shared and production environments.

To address these challenges, the authors advocate for the implementation of branch environments. Branch environments are independent, isolated setups for developing and testing specific features or issues. These environments, when paired with tools like Terraform, Argo CD, and Helm, enable integration with Infrastructure as Code (IaC) and GitOps, automate infrastructure management, and ensure automatic cleanup of unused resources. This approach promotes consistent documentation of dependencies and application details within version control systems like GitHub. The blog includes a clear diagram and code snippets that effectively demonstrate how to set up branch environments using these tools, making it accessible and actionable for readers.

Branch environments offer several key advantages. By isolating changes, they ensure that all updates are properly tracked, simplifying debugging and maintaining consistency across development efforts. This isolation also eliminates conflicts inherent in shared environments, reducing the risk of outdated configurations or data interfering with new testing and development efforts. Tools like Terraform and Argo CD further enhance this process by automating repetitive tasks such as infrastructure provisioning and application deployment, saving developers time and reducing the likelihood of human error.

Additionally, branch environments improve resource efficiency. Since these environments are ephemeral, they are cleaned up automatically when no longer needed, freeing up valuable system resources and lowering costs. The inclusion of tools like Helm simplifies configuration management, even for complex architectures, ensuring a streamlined, manageable workflow.

Overall, this blog provides a thorough and practical framework for tackling one of the most common challenges in software development: creating reliable and consistent environments. The adoption of branch environments combined with IaC and GitOps principles enhances scalability, collaboration, and efficiency. As I continue to develop my own projects, I plan to incorporate these strategies and tools to build environments that are both robust and resource-efficient.

From the blog CS@Worcester by cameronbaron and used with permission of the author. All other rights reserved by the author.

This week, I am focusing on the blog “The Software Architect: Demystifying 18 Software Architecture Patterns.” by Amit Verma. Verma is an architect who focuses on creating Java applications among other work. This blog aligns with our course work as we focus on software architecture and we have recently learned the details related to some of the design patterns mentioned here. This post has introduced me to new architecture design patterns to study and provided a vast array of knowledge like when to apply them and how to properly use them in my future projects.

Verma begins by specifying what software architecture is and how it differs from software design. I appreciate how this was explained because it makes the concepts simple to understand. Software architecture focuses on the high-level structure like the blueprint of the project, software design focuses on translating this blueprint into real project specifications which developers can implement. A concept in this post that was new to me was the architecture documentation approach, the C4 model. This model ensures that there is a structure that is able to be implemented by addressing four main levels: context, containers, components, and code. The C4 model encourages architects to create diagrams and written documents to ensure comprehensive project documentation.

The beauty of architectural patterns lies in their repeatability; they provide reusable solutions that address common goals and challenges across projects, enabling architects to achieve a specific, predetermined outcome efficiently. This post provides information related to 18 different architecture patterns that are commonly used and necessary for software developers to be familiar with. Some of the patterns were entirely new to me like the Layered Pattern, Pipe-filter Pattern, and the Microkernel Pattern. Beginning with the Layered Pattern, this architecture separates different functionalities into different layers. One common representation of this uses three main layers, the presentation layer which responsible for the UI and other user-focused components, the business logic layer which focuses on the business rules and the actual code to manage data and make calculations, and the data access layer which is handles database/external data source interactions. Next, the Pipe-filter Pattern uses independent components to process data using separate processing tasks. Beginning with the data source, moving into the pipe which connects components, then using filters to transform the data based on a given function, and finally the data sink or endpoint which receives the processed data output. Lastly, the Microkernel Pattern a.k.a. Pluggable Architecture allows for modular, flexible systems to be built. In this architecture, the system’s core services are handled in the microkernel and all other components are separated known as a plug-and-play concept.

This post is rich with vital information related to software architectures and provides knowledge far beyond what I have included here. I know I will be returning to this blog repeatedly as a resource to learn from and to use a basis of how these patterns can be implemented.

From the blog CS@Worcester by cameronbaron and used with permission of the author. All other rights reserved by the author.

Week-15: 12/21/2024

It’s easy to get something functional, but is it good? The book “Clean Code” by Robert C. Martin shows how my past coding techniques were wrong. This book isn’t just about making code work; it’s about crafting code that is understandable, maintainable, and, dare I say, beautiful.

The book highlights the importance of seeing code as a kind of communication rather than simply computer instructions. It’s about creating code that’s simple to understand, alter, and, ultimately, live with. The book provides several definitions of clean code, including the following: elegant, efficient, simple, straightforward, and carefully crafted. It also covers ideas and practices including utilizing meaningful names, constructing concise functions, correct commenting, formatting, error handling, unit testing, and so on. The book depicts the transition from sloppy to tidy code. It also includes a collection of code smells or heuristics that might help you write better code. 

I chose this book because I often find myself spending more time deciphering what code does than actually adding new features. I was looking for guidance on how to avoid creating such a mess and to understand what makes code easy to work with, and the book seemed highly relevant to my goals as a student. I also appreciated the idea that code is read far more often than it is written, so making it easy to read is very important.

This book has opened my eyes, particularly to the importance of code readability. It is not enough to have code that is functional; it must also be understandable to everybody who will work with it. This is particularly crucial in collaborative efforts. The author’s description of “code sense,” a carefully developed feeling of ‘cleanliness,’ struck a chord with me. Knowing that code should be clean isn’t enough; we also need to learn how to make it clean. 

I will be putting the principles of “Clean Code” into practice by always striving to leave the code cleaner than I found it. I also plan to be more diligent in naming variables and functions, keeping functions short and focused, and implementing tests to validate and describe code. This book has taught me that clean code is more than a nice-to-have; it is an important component of becoming a professional software developer. I now recognize that “working” code is only the first step; “good” code needs ongoing attention and effort. I’m excited to implement these concepts into my future projects, not just to improve my grades but also to gain more experience programming software.

Book: Clean Code: A Handbook of Agile Software Craftsmanship by Robert Cecil Martin

From the blog CS@Worcester – computingDiaries by hndaie and used with permission of the author. All other rights reserved by the author.

Week-15: 12/20/2024

This blog post really helped me understand how important design patterns are for making REST APIs that are easy to use and can handle a lot of traffic. The post talked about things like naming resources consistently, breaking up big chunks of data into smaller pieces, and making sure that updates don’t break older versions of the API.

One thing that really stuck with me was how important it is to name your resources consistently. The post emphasized that using standard and intuitive naming conventions makes APIs predictable for other developers. It’s like having a well-organized filing system—if everyone knows where things are supposed to go, it’s much easier to find what you need.

The post also talked about things like versioning and error handling, which are super important for making sure that your API can evolve over time without breaking things for people who are already using it. Versioning ensures backward compatibility as APIs evolve, which means that even if you make changes to your API, older applications that use it will still continue to work. Error handling is all about giving developers useful information when something goes wrong. The post mentioned that providing informative error responses can help guide developers who are using your API. I’m definitely going to be focusing more on these aspects in my future projects.

The reason that I chose this blog post was because it aligns closely with what I learned in the class. Our class discussions often emphasized the best practices for creating maintainable, user-friendly APIs, and this post serves as a practical extension of those theoretical concepts. I wish I had read this article before some of my homework assignments; it would have made it easier for me to understand the assignments. Additionally, its concise, actionable guidance provides a clear framework for applying these principles in real-world scenarios.

Overall, this blog post was a great way to connect the theoretical stuff we’ve been learning in class with how things actually work in the real world. It’s one thing to understand these concepts in theory, but it’s another thing to see how they’re applied in practice. This blog post provides practical insights into designing APIs that are easy to use and can be scaled up as needed. It’s given me a much better understanding of how to create APIs that are not just functional but also developer-friendly and built to last.

Blog link: https://blog.stoplight.io/api-design-patterns-for-rest-web-services

From the blog CS@Worcester – computingDiaries by hndaie and used with permission of the author. All other rights reserved by the author.

The planning process is an open source project is often created and monitored by the maintainers. This blog intends to go over the commonalities found by Safia Abdalla in open source planning mentioned in her article “Open source excursion: The poetry of planning”. I chose this topic because it relates to both the section in class where we went over licensing, which included open source licenses, and the section where we over different planning philosophies like scrum.

The first shared tendency between open source maintainers Abdalla lists planning with the intent to build excitement in the community that might hold many of your future contributors. Maximizing the outreach your plan gets among possible contributors and consistently providing updates when changes are made attracts attention towards your project, increases your chances of acquiring new contributors, and encourages existing contributors. Another common planning practice Abdalla lists is planning to prioritize. This planning method aims to optimize the process by which user requests and pull requests are fulfilled by distributing the responsibility among a chosen team. This allows for the efficient processing of requests, as well as allows many members of the team to get well acquainted with the user community and their hopes for the team’s project. The last 2 planning methods listed by Abdalla are planning to communicate and planning incrementally. Planning to communicate is a method of planning that, once a projects priorities and goals are well defined, aims to communicate those goals with the community. This leads to more exposure for the project, and possibly more support and contributions to it as well. Planning incrementally is a planning method where members of a team are mindful of the dynamic nature of the planning process, and communicate to the communities interested in the project the same thing, as to not mislead them.

Overall, these commonalities between open source planning all seem like good habits, and practices that would be useful for me to employ as a future open source project maintainer, and would also be useful as a contributor to open source projects to be aware of these tendencies so I can better align my work to the maintainers’ planning strategies. Planning with the intent to build excitement, along with being an effective planning strategy, sounds like it would also help for beginner developers to build a presence for themselves in the communities that are interested in the project that’s employing it.

https://increment.com/planning/open-source-planning/

Link to source blog:

From the blog CS@Worcester – My first blog by Michael and used with permission of the author. All other rights reserved by the author.