The article I chose shows how strongly front-end design is linked to the structural principles I learn in Software Construction, Design, and Architecture. This is important to know because front-end design is often seen as the “visual” or “creative” side of development. I wanted to look into how these ideas apply to the front-end world because our class focuses on making systems that are scalable and easy to manage through patterns, abstractions, and good architectural choices. To show that UI design and software architecture are more connected than many developers think, this piece built a strong link between the two.

The article says that front-end architecture is a planned way to arrange code, components, styles, and interactions so that the app stays the same and can grow over time. The book talks about practices like using clear naming standards, modular components, reusable patterns, and separating concerns. These are all very similar to ideas covered in the course, such as the Stratified Architecture Model, the SOLID principles, and design patterns like Strategy, Factory, and MVC.

The idea that front-end design isn’t just about how things look but also how they are put together is one of the most important things I learned from the resource. In the same way that writers plan backend classes, the author says that UI components should be planned with clarity, purpose, and future change in mind. This made it easy for me to see how front-end design and software systems are connected. The same goals we have when using architectural principles to build software are met by a well-structured front end: fewer bugs, better teamwork, and easy addition of new features.

When I thought about this, I noticed how often developers rush through UI design without thinking about how to keep it up to date over time. I changed how I build interfaces because of the text. I used to only care about “making it look right,” but now I know how important it is to make parts that can be used again, are predictable, and fit in with the general architecture of the system. This fits with what I’ve learned in class about cutting down on duplicate code, making things more cohesive, and keeping the lines between layers clear.

In the future, I’m going to use what I’ve learned by making a library of components early on in a project, writing down UI rules, and making sure that the front end and back end can talk to each other clearly through well-structured APIs. In addition to making development go more smoothly, this method will also make the product easier to expand as more features are added. In general, this resource helped me learn more about how software building principles affect more than just backend logic and have a big effect on the quality of front-end systems as well. It also told me that software architecture and user experience are linked—a well-designed system helps a well-designed interface work.

From the blog Site Title by Roland Nimako and used with permission of the author. All other rights reserved by the author.

Design patterns are an important part of the course, but I have only touched on them briefly so far. This piece is a clear and easy-to-understand introduction to them. To connect theory and practice, I thought the article’s way of explaining what design patterns are, why they’re important, and how they’re grouped would be perfect. This is because I’m learning how to code and thinking analytically about how software is built and designed. Using my skills in finance and data analysis to look at software systems in a more structured and planned way also fits with this goal. 

A brief summary.
Design patterns are described in the piece as “reusable templates that empower developers to address recurring challenges in software design.” Type: Medium. It informs the reader that a design pattern is not complete code, but rather a plan or idea that can be used in various situations. It uses Christopher Alexander’s ideas to show how patterns came to be and sees the famous book by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (1994) as a turning point. Medium Later, the piece divides patterns into three common groups: creational (how objects are made), structural (how objects and classes are put together), and behavioral (how objects talk to each other). Medium+1 Instance Singleton (ensures one instance), Factory Method (abstract object creation), Observer (object communication), and other examples are given. Patterns have perks like better code reuse, maintainability, communication among developers (shared vocabulary), and the ability to be extended. Medium. It also doesn’t sugarcoat criticism, pointing out that patterns should only be used carefully so they aren’t over-engineered or used in the wrong way. Medium. 

Personal reflection.
I learned more from reading the piece that design patterns are not just academic artifacts, but very useful tools for building and architecting software. I now understand that as I work on projects (for school, fun, or future work), I can look for problems that keep coming up (like “we keep instantiating similar objects in different ways”, “classes in our system are tightly coupled”, or “object behavior changes depending on state”) and think about using a good pattern instead of coming up with a new solution every time. 

Conclusion
Overall, this article on design patterns provided a strong foundation that I can build upon. It made it clear what design patterns are and why they’re important. It also provided me with a clear structure (creational, structural, and behavioral), and it made me think about how I will utilize patterns in my work as I transition into a more business-focused software professional. I will keep this resource and its tips in mind as I learn more about building, designing, and architecting software.

References: 

It was written by Freeman, E., Sierra, K., and Bates, B. First, look at the design patterns. The O’Reilly Media.

Smith, C. Alexander (1979). What’s Always the Best Way to Build? Oxford College Press.

From the blog Site Title by Roland Nimako and used with permission of the author. All other rights reserved by the author.

In this episode, Ashley Peacock, a staff engineer and architect who is passionate about visualizing software ideas, is interviewed by host Akshay Manchale. They examine the reasons behind the underutilization of diagrams in software engineering, the rise and fall in popularity of modeling tools and notations (such as the traditional Unified Modeling Language, or UML), and, most importantly, the continued significance of sequence diagrams. Sequence diagrams have two primary uses, according to Peacock: (1) depicting user flows through a system (actor → service → backend → database) and (2) illustrating message flows between classes/components in code. He highlights the fundamental function of diagram communication instead of discussing the drawbacks of overly rigorous UML adoption.

The reason I chose this Source

I chose this episode because our course on Software Construction, Design & Architecture emphasizes modeling techniques, and I wanted to learn more about how sequence diagrams are used in modern software engineering practice than just the concepts found in textbooks. Hearing a practitioner discuss diagramming in real-world scenarios felt incredibly relevant to me as someone with a background in finance and statistics who wants to improve my technical design abilities (particularly because modeling can be used in business/technology initiatives). 

Reflections And Actions

It became clear to me again while listening to Peacock that what matters most is how well you communicate, not how well you write. I discovered that sequence diagrams are more than just “another UML artifact.” They connect use-case thought (what the user does) and structural modeling (what the system has). Making a sequence diagram of the steps “User submits order; OrderService validates; InventoryService checks stock; PaymentGateway processes payment; confirmation sent to user” can help everyone (business, product, architecture, and development) understand the flow. At the beginning of my work, I also put too much emphasis on static diagrams like class and ER diagrams and not enough on the temporal aspects of “who calls whom when” and “what’s the sequence.” I learned from the show that sequence diagrams can be used as a contract: you can map out how things work together before you write any code, which helps you avoid misunderstandings.

To improve my future work, I will choose a key scenario (like “customer checkout,” “report generation,” or “billing and collections”) and make a sequence diagram to help me understand it better when I do system analysis for a project, whether I’m a financial or technical analyst or designing a business process. The chat changed how I think about tools. I’m going to start using lightweight diagramming tools (Mermaid, PlantUML, etc.) that let diagrams live with code instead of being buried in PowerPoints. I can see that sequence diagrams aren’t just ideas; they can also be used to communicate design ideas, make sure that architectures are aligned, and keep records.

Citation

I’m Ashley Peacock. (5/31/2023). Ashley Peacock talks about diagramming in software engineering on SE Radio 566. se-radio.net

From the blog Site Title by Roland Nimako and used with permission of the author. All other rights reserved by the author.