Software architecture is one of those concepts that students hear often but rarely get a clear definition of. This week, I chose to read Martin Fowler’s Software Architecture Guide because it went into depth beyond surface-level definitions of architectural thinking that we usually hear. Since our course is so strongly focused on building maintainable and scalable systems, this resource fit perfectly with the themes we have discussed around design decisions and long-term maintainability in software projects.

Fowler opens the guide by addressing one of the most debated questions in the software community: What, really is architecture? He explains how many definitions focus on “high-level components” or “early design decisions,” but argues these views are incomplete. Referring to an email exchange with Ralph Johnson, Fowler insists that architecture is about “the important stuff.” Architecture is not about big diagrams or an early-stage structural choice; it is about experienced developers having a common understanding of the parts of a system that matter for its long-term health. This makes architecture dynamic and changing rather than merely static documentation.

Fowler also describes why architecture matters, even when end users never directly see it: A poor architecture leads to “cruft,” or the buildup of confusing, tangled code that slows down development. Instead of enabling fast delivery, weak internal quality ultimately hurts productivity. The argument here by Fowler is that paying attention to internal structure actually increases delivery speed because developers spend less time fighting the codebase and more time building features. What struck a chord for me in this is how architecture is coupled with practical results: maintainability, reliability, and team productivity.

I chose this article because I really enjoy the topic and wanted to learn more about software architecture in depth. Fowler’s explanation really helped me understand that architectural thinking is something developers grow into by learning to identify what is truly important in a system. This directly connects with the principles we’ve discussed in class around clean code, modularity, and design patterns. Reflecting on the material, I realized that in future software projects, including class assignments, internships, I will have to think about how my design decisions today will affect my ability-and my team’s ability-to maintain or extend the system later. Good architecture supports future evolution, as Fowler put it, and this is something I want to actively apply as I head toward more complex development work.

Resource: https://martinfowler.com/architecture/

From the blog Maria Delia by Maria Delia and used with permission of the author. All other rights reserved by the author.

This semester I finally sat down and untangled the confusing world of software licenses, starting from a basic question: what can you actually protect when you write code? One of the first things I learned is that you cannot copyright a mere idea for a program; copyright law only protects the concrete expression, like source … Read more

From the blog CS@Worcester – BforBuild by Johnson K and used with permission of the author. All other rights reserved by the author.

Getting to grips with making REST API calls felt like finally being able to have a real conversation with the internet. At first the whole thing was a bit too much but once I started to see the patterns emerging, it just became second nature. It all clicked when I realised that a REST API … Read more

From the blog CS@Worcester – BforBuild by Johnson K and used with permission of the author. All other rights reserved by the author.

For this third quarter’s professional development, i read the Treblle post, “How to Structure an Express.js REST API with Best Practices” (https://treblle.com/blog/egergr). The article mostly just talks about on how to properly organize and build RESTful APIs using Express.js while maintaining clean, scalable, and modular code. It covers some key principles like separating app and server logic, implementing a layered architecture, structuring routes and controllers clearly, and designing the API in a way that’s easy to maintain and expand. It also makes mention on the importance of using Docker for containerization and environment consistency, which is essential for deploying APIs reliably across different systems.

I picked this specific resource because i think it ties closely with what we’ve learned in class earlier, taking into account the things like modularity, separation of concerns, and maintainable software design. It helps that we were doing class exercises when it comes to building small web services and understanding how system components interact(at least tangentially when it comes to the guestinfobackend stuff), so reading about how Express.js projects are structured in real-world settings gave a lot of context for people such as myself interested in backend or full-stack development, it’s the kind of practical foundation that helps turn classroom principles into actual coding habits.

From the article, I learned that Express.js isn’t just about setting up endpoints quickly; it’s about creating a clear, layered structure where each part of the API has its own responsibility. In one instance, it recommended dividing the project into three layers: a web layer (for routes and middleware), a service layer (for handling logic and validation), for the other a data layer (for managing database access). I’d say this structure kind of keeps your code modular and easier to debug. Another thing I think is useful was the reminder to containerize the API using docker, which helps standardize development and production environments so you can avoid those “it does/doesn’t work on my machine” problems.

I’d say the article reinforces many of the software architecture concepts we’ve referenced in class, such as modularity, abstraction, and loose coupling. A modular API design definitely makes it easier to scale, test, and maintain which at the end of the day is really the heart of software construction. It also reminded me that tools like Docker play a key role in supporting architecture by making deployment consistent and repeatable, which is just as important as how the code itself is structured.

As a whole, i’d say this article helped me better understand what good backend architecture looks like in practice. It gave me a clearer sense of how to build modular, scalable APIs using Express.js and Docker and i can somewhat see how those principles might carry over into any kind of future coursework and professional projects that i might be part of.

From the blog CS@Worcester – CSTips by Jamaal Gedeon and used with permission of the author. All other rights reserved by the author.

In the workplace, not only do the number of projects continue to increase, but the way in which we approach them exponentially increases as well. Tech professionals are leading the way in developing cutting edge procedures and processes for daily work, tracking and planning. Tools rapidly evolve as well, so with that being said, project management has been a lot more interesting to say the least.

Adapting to new technologies and routines is the best way to be efficient. With the changes between roles and systems of project management, there needs to be some solutions (or at least one). According to the Forbes Technology Council, they have detailed emerging trends and strategies to inform various organizations. By counting off the actions in this list, we get to see an evolution within different companies and organizations if they feel encouraged enough to take them into consideration.

Starting off, project managers need to establish a V.M.O (value management office). It is the idea of shifting the focus from project delivery to value maximization. For example, if an organization has an initiative, they align it with different goals and efficient resource use to allow for continuous improvement. It is absolutely essential, especially in today’s climate of business and organizational behavior.

Never be afraid to rely on the professionals in times of need. This article highlights the importance of relying on “senior talent”. Since they have the broadened experience, they’re capable of making quick and well informed decisions. For more complex projects, this proves to be useful, helping project managers understand business goals by creating emphasis on exceptional product ownership skills.

I told you AI is not always a bad thing. A lot of individuals, including myself, believe in the power of AI being used as a tool. It’s no secret that several organizations use it, but it is very important to note how its being used. This is called resource optimization. By allocating these resources accordingly, complexities can be well more managed. Artificial intelligence can assist with communication, task automation and provide data insight, leading to greater outcomes/output.

For me, specifically reading just the title alone, I was thinking of more teamwork-driven strategies and trends, similarly to the SCRUM and Sprint conversations during lectures. Of course, I judged a book by its cover and I knew immediately that I had to read and dissect this story. It is important to acknowledge that this article is from a year ago, meaning that more and more trends have been created at this point. These strategies however are still very applicable to today’s modern climate of process management.

As a tech person, or any business person, it is crucial to stay optimistic and see the value in making changes. I believe that myself and my generation have the potential and resources to evolve areas in their career field, with ideas that we want to see unfold. It will be very interesting to see the growth.

Source: 20 Emerging Strategies And Trends In Project Management

From the blog CS@Worcester – theJCBlog by Jancarlos Ferreira and used with permission of the author. All other rights reserved by the author.

I wrote my blog based on “What is encapsulation in object-oriented programming (OOP)?” from Cincom Systems Blog. The blog defines encapsulation as bundling data, specifically attributes, and the methods that operate on that data into a single unit, while restricting access to some of the class’s components. The author explains well what we learned in previous classes, that using access modifiers like private and protected, a class can hide their internal state while exposing only controlled interfaces to the outside world. It goes on to describe benefits of encapsulation. Improved modularity, protected internal state, easier debugging and testing, and cleaner interfaces. The article also gives good practices based on the idea of encapsulation.

This blog directly relates to many things that we do in this class, practicing OOP and clean coding. I picked this article because it not only defines the concept of encapsulation but also connects it with practical ideas in software design and maintenance. I felt this article would help remind me on the theory of encapsulation and OOP.

Reading this article reminded me that encapsulation isn’t simply making variables private and using setters and getters but it’s about letting the class control its own state and hide implementation details from the outside world. This blog made me review some of my past projects where I had too many exposed public fields that made the code less clean. My past projects are definitely not written well with encapsulation in mind so reviewing this topic was extremely helpful.

Going forward, in personal coding and team projects, I expect to apply encapsulation and OOP in general by designing classes so that their internal data is private or protected, and only the necessary operations are public. Ensuring that external code interacts with objects via meaningful methods rather than manipulating internals directly.

To summarize this blog. It helped me remember what encapsulation actually means as a core OOP design principle rather than just an after thought. Applying what I learned from this blog, I expect to improve upon writing code that is cleaner and less error prone.

https://www.cincom.com/blog/smalltalk/encapsulation-in-object-oriented-programming/

From the blog CS@Worcester – Coding with Tai by Tai Nguyen and used with permission of the author. All other rights reserved by the author.

I recently read the blog post titled “Why Code Reviews Are My Highest-Priority Work” by Jordan Edmunds. In the article, Edmunds explains why he regards code reviews as the top priority work. He outlines several reasons. First, that doing reviews early reduces the team’s merge conflicts and speeds up cycle time. He also notes that if a review happens soon after the author writes code, the author still has fresh context, making fixes and tests easier. He points out that timely reviews improve overall team productivity, and supports shared responsibility. He discusses common objections and shares how he integrates reviews into his day.

This blog post directly relates to our course topic of Code Review. I chose it because rather than just defining what code review is, Edmunds gives practical ideas into why it matters, based on real experience in a programming context. Since our course material covers this topic, this article provides a good example of how Edmunds’s code review ideas is applied. I felt it would help me connect theory with real practice.

Reading the article made me realize that code reviews aren’t just an after the thought thing to checkbox but a good practice for improving code quality. I learned that timing matters, a review done soon after code submission is far more effective than one delayed. I also like the emphasis on context, for the programmer, having fresh understanding of their changes makes review feedback much easier. These ideas provided by Edmunds helps shape how I think about code reviews now. I’ll aim to review often and hopefully the fresh context will help me pinpoint any and all problems present.

Personally, this article made me reflect on my own habits where I often skip reviews or wind up doing them late, when I encounter a problem running my programs. I’m now aware that this can slow feedback and especially development. After reading this blog, in any coding assignment or personal project, I plan to start reviewing written code quickly. Reviews are an important process which we upkeep standards, share progress, and improve code maintainability.

In summary, this resource has helped me understand the value of code review, and given me good ideas for applying it in team and personal works. By participating actively and thoughtfully in code review, I’ll hopefully write better code and contribute to smoother team processes.

https://medium.com/%40jordan.l.edmunds/why-code-reviews-are-my-highest-priority-work-8e9b4c410887

From the blog CS@Worcester – Coding with Tai by Tai Nguyen and used with permission of the author. All other rights reserved by the author.