Resource Selected:
“Patterns of Legacy Displacement” by Ian Cartwright, Rob Horn, and James Lewis
Published on Martin Fowler’s Software Architecture site
https://martinfowler.com/architecture/

Summary of the Resource

This article explores the practical challenges of replacing legacy systems in large-scale organizations. The authors introduce the concept of the “legacy replacement treadmill,” a cycle in which enterprises launch extensive modernization efforts that often stall or fail before meaningful progress is made. The authors argue that the core issues extend beyond outdated technology to include organizational and leadership shortcomings. To address these challenges, they recommend setting clear goals, delivering improvements in small, manageable increments, and avoiding “big-bang” system rewrites which typically lead to failure. Instead, they propose a more sustainable approach: gradually isolating and updating parts of the legacy system, delivering functional components, and slowly retiring the outdated codebase.

Why I Chose This Resource

I selected this article because it directly relates to key principles we’ve discussed in our software design and architecture course, such as maintainability, technical debt, and scalable architecture. Rather than just presenting theory, the article demonstrates real-world consequences when these principles are overlooked. Additionally, I’ve observed similar patterns on a smaller scale during team projects, where the instinct to start from scratch often feels easier than improving existing code. This resource provides a practical, realistic alternative to that approach.

Reflection and Key Takeaways

The most impactful lesson for me is that modernization should not be seen as a rapid technical overhaul but as a long-term, structured effort. The authors emphasize defining clear outcomes before writing any code a concept that shifted my perspective. In future projects, I aim to prioritize measurable objectives over vague goals like “make it better.”

Another important insight is the risk of pursuing feature parity with legacy systems. Attempting to replicate every existing feature can hinder innovation and slow down progress.

The article also deepened my understanding of how human factors such as team habits, organizational power structures, and internal priorities can influence the success or failure of architectural changes. Even the best-designed technical solutions will struggle to succeed without cultural alignment and support for gradual transformation.

Moving forward, I intend to apply this mindset to legacy code by introducing incremental, testable changes that improve the system’s architecture over time. This approach may be slower, but it is ultimately more effective and sustainable.

Link to the Resource:
https://martinfowler.com/architecture/

From the blog Zacharys Computer Science Blog by Zachary Kimball and used with permission of the author. All other rights reserved by the author.

Link: https://codibly.com/blog/articles/yagni-how-to-do-things-when-you-actually-need-them-to-be-done

The blog post “YAGNI – how to do things WHEN you actually need them to be done” goes over the YAGNI (You Ain’t Gonna Need It) principle and why it is necessary as a guardrail against over-engineering in software development. The blog starts off by explaining the origins of YAGNI, as it originated from eXtreme Programming (XP) used in agile software development teams. Essentially, YAGNI should be used so that developers can resist the urge to implement features that are not necessary or needed. The blog compares YAGNI to KISS (Keep It Simple, Stupid), as while KISS advocates for more simplicity overall, YAGNI is more focused on discouraging unnecessary functionalities. The blog also goes over the risks of over-engineering, as it can lead to more bugs and simply be a burden when it comes to maintenance. Furthermore, it can also just lead to making your code way more complex for no reason. In the end though, in order to apply YAGNI in a responsible way it requires good judgement, as some additions are harmless as long as they don’t increase the complexity, but generally speaking it is better to keep it clean and simple.

I picked this blog post because I think that this is very important practice that will apply to a workplace environment. You always want to plan ahead and implement features that may be needed in the future, but overdoing it is not good. It is very important to find a balance, as doing too much of either can lead to big problems. For our course, this blog post also covers other software design principles, as well as some agile practices too. I think that all of these principles are very important for when it comes to working in a team environment, which is something that I will most likely have to do in the future. In a team environment, it is important to make sure your code is not complex, as other people will have to read it and potentially debug it as well.

Going forward, I plan on applying YAGNI principles to my current code as well as any code that I work on in the future. This blog gave me a good reminder that just because we might need an abstraction in the future, that doesn’t mean that we have to add it now. This can just lead to more maintenance, bugs, and just unnecessary complexity. I can apply these principles favoring simple versions of programs, as well as consistently reevaulating the requirements of a program. Overall, this blog post on YAGNI gives a great view and perspective on a principle that is very important in software design.

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

The blog post/article I choose to read and write about is Mastering OOP Fundamentals with SOLID Principles from the ByteByteGo blog page. This blogpost goes into many aspects of the OOP programming, some of which we’ve discusses in class. The first portion delves into Encapsulation, Abstraction, Inheritance, and Polymorphism. It explores some key concepts like single inheritance, multiple inheritance, multilevel inheritance, hierarchical inheritance, method overloading, method overriding, etc. It explains how these 4 fundamentals are important for creating and utilizing OOP effectively, but in and of itself doesn’t necessarily create code that is easy to work with and maintain.

That’s why it introduces the principles of SOLID, which according to the syllabus is something we will eventually touch on in the future. The S is for Single Responsibility Principle, stating that classes should only have a single reason to change. This ensures better organization, easier debugging, and improved testability, so it’s better to split a complex class into multiple simplified classes. The O stands for Open/Closed Principle, stating that classes should be open for extension, but closed for modification. Essentially, if we want to add new behaviors to a class, new subclasses or interfaces should be added without changing what already exists. The L stands for Liskov Substitution Principle, stating that “objects of a derived class must be replaceable by objects of the bass class without altering the program’s correctness.” A subclass shouldn’t break existing functionality while behaving like it’s parent class. This somewhat relates to the interface portion of what we did in class. The I stands for Interface Segregation Principle, stating that clients should not be forced to depend on unused interfaces. Essentially, interfaces should be small and specific, with only relevant methods. Finally, the D of SOLID stands for Dependency Inversion Principle. This states that high-level modules and low-level modules should depend on abstractions, rather than each other. This can help improve flexibility and mobility, so that it’s easier to test and work with without making as many modifications.

The reason I chose this blogpost/article is because it directly relates to what we’ve learned with the fundamentals of OOP so far, as well as introducing me to something that’s planned for the syllabus. I also saw it as a good primer for Java and OOP thinking to help me better understand the general ideas and concepts that hold it up.

Even though a good portion of what was written is just reiterating some of what we’ve discussed in class, I found it really helpful to have things explained another way with the examples the blogpost gave. It helped me better grasp the purposes behind these fundamental principles and ideas in a way that felt easily digestible. The SOLID portion was also interesting, and everything intuitively makes sense. I can definitely see myself referring back to this and sticking to these ideas as I do OOP programming in the future, because it genuinely does seem to make the code easier to work with and easier to understand.

From the blog CS@Worcester – Site Title by Justin Lam and used with permission of the author. All other rights reserved by the author.

Hi, 

For this blog post I have chosen the topic design patterns in software construction. I watched the video linked below which is titled Design Patterns in Plain English | Mosh Hamedani by Mosh which does a great job of showing how design patterns in software construction work. https://youtu.be/NU_1StN5Tkk?si=aFdc2v01YIvoGq0m

Firstly, we must understand what exactly a design pattern is with respect to code. Design patterns are reusable solutions to common problems in code. From here we can make the inference that the goal of a design pattern is to build reusable and extensible software. To help us achieve this, there are three main categories which are creational, structural and behavioral patterns. Creational patterns regard different ways to create objects. Structural patterns are about the relationship between those objects. Behavioral patterns are about the interaction/communication between objects. From these categories we would choose which one to use based on the specific problem to implement the design pattern.

To help with the process of a design pattern, you would want to use a UML diagram to better visualize and understand the whole code. This way you will be able to see the type of relationships from one body to another; whether it’s inheritance, composition, and/or dependency to name a few. Something you may see on the UML diagram could be an interface.

An interface is a powerful tool that is often used in design patterns. Furthermore, they promote loosely coupled apps and flexibility. With an interface in the design pattern it strives substantially towards the overall goal which is to build reusable and extensible software.

Mosh then goes on to discuss and show the four principles of object-oriented programming, which are encapsulation, abstraction, inheritance, and polymorphism. Encapsulation deals with bundling data and the methods that operate on it into a single unit or class and hiding the values or state of an object within a class. In coding, abstraction is in regards to reducing complexities by hiding unnecessary details in classes. A great example of abstraction to better understand is thinking of a tv remote control; it shows only what you need to see. The next one is inheritance. Inheritance is a mechanism for reusing code across classes including common behavior. Try thinking of a parent to a child class. The child class inherits the parent class, but also has instances and methods of their own. Polymorphism is the ability of a single object to take many different forms. Mosh stresses that you must know and understand these principles as they are crucial to building design patterns.

Some takeaways are understand the problem you are facing first, have a strong foundation in OOP, and know when not to use a design pattern. Furthermore, creating multiple classes or a new interface just for one or two actions of a given state is simply not worth it; go with the else if statement.

From the blog CS@Worcester – Programming with Santiago by Santiago Donadio and used with permission of the author. All other rights reserved by the author.

I want to introduce a powerful tool in the arsenal of software engineers aiming to write clean, flexible, and maintainable code. The tool that most developers would need to upgrade the code without modifying the existing client code , and it is particularly helpful in scenarios involving algorithms of your code. The tool is called “Strategy Pattern“.

Strategy Pattern is a behavioral pattern that enables the selection of algorithms at runtime. This tool is crucial for developing flexible, maintainable, and modular code. Especially when multiple algorithms are applied to solve a problem. The key goal is to allow software entites be open for extension but closed for modification, meaning without having any impact or changed on the client code, but modifying and extending it.

Type of Strategy Pattern

1. Context – Holds a reference to a Strategy, delgates work to it. The Context doesn’t implent algorithm logic itself.
2. Strategy Interface – Defines a common method (or set of methods) that all strategies must implement, so they’re interchangeable.
3. Concrete Strategies: Classes implementing the Strategy interface, each providing a different algorithm implementation.

Benefits

1. Flexibility – New strategies can be added without modifying existing code.
2. Seperation of Concerns – Context is freed from algorithm details; each strategy handles its own logic
3. Easy to test: You can test each strategy class independently.

Disadvantage scenario

• Using pattern strategy creates more classes to manage, which can complicate desgin
• Some abstraction layers which may or may not be worth it in simpler scenarios.

Conclusion

The startegy patterns is useful when you have multiple algorithms or behaviors that needs to be added or swaped dynamically, in order to solve problem without impacting the existing code. It helps you build modular, maintainable, and extensible systems. But you should be mindful about the extra complexity it comes with.

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