Why Your Code Always Feels Wrong (And That's Okay)

Every developer faces the same impossible choice: keep all your logic in one place and watch it become an unmaintainable monster, or split it across multiple files and create a maze where simple changes require archaeological expeditions through twelve layers of indirection. This isn't a sign you're doing it wrong—it's the fundamental tension of software architecture. The good news? Both approaches are tools, not traps. Understanding when to use monolithic clarity versus distributed modularity, and having the courage to refactor between them as your system evolves, is what separates thoughtful architecture from cargo-cult pattern following. Your code will always feel imperfect, and that's exactly how it should feel when you're working on something complex enough to matter.

Architecture Design Philosophy

 Evolution of software architecture

Welcome to The Pragmatic Engineer! Today, I’m thrilled to be joined by Grady Booch, a true legend in software development. Grady is the Chief Scientist for Software Engineering at IBM, where he leads groundbreaking research in embodied cognition. He’s the mind behind several object-oriented design concepts, a co-author of the Unified Modeling Language, and a founding member of the Agile Alliance and the Hillside Group. \r\n\r\nGrady has authored six books, hundreds of articles, and holds prestigious titles as an IBM, ACM, and IEEE Fellow, as well as a recipient of the Lovelace Medal (an award for those with outstanding contributions to the advancement of computing). \r\n\r\nIn this episode, we discuss:\r\n• What it means to be an IBM Fellow\r\n• The evolution of the field of software development\r\n• How UML was created, what its goals were, and why Grady disagrees with the direction of later versions of UML\r\n• Pivotal moments in software development history\r\n• How the software architect role changed over the last 50 years\r\n• Why Grady declined to be the Chief Architect of Microsoft – saying no to Bill Gates!\r\n• Grady’s take on large language models (LLMs)\r\n• Advice to less experienced software engineers\r\n• … and much more!

Architecture Philosophy Video

 Designing Fault-Tolerant Software with Control System Transparency

GN&C Fault Protection Fundamentals by Robert Rasmussen, who works for the Jet Propulsion Laboratory, which is an organization that works closely with NASA on designing spacecraft. GN&C is guidance, navigation, and control. These are the main software systems here. This paper actually distills a ton of experience spent with really thinking through how to build really fault tolerant systems into some core principles.

Architecture Distributed Systems Video

 12 Software Architecture Pitfalls and How to Avoid Them

Developing a successful software architecture is simple, but it’s not easy. Understanding QARs and then understanding and making the trade-offs that will maximally satisfy the QARs takes insight and experience, much of which has to be gathered through iterative experimentation on the architecture itself. The process itself is simple, but the trade-offs that need to be considered are often tough, and there are seldom easy answers.

Architecture Best Practices Design

 Consistency Models

Architecture Distributed Systems Software Engineering

 Granularity & Communication for Microservice Architectures

Architects struggle in modern distributed architectures with two Hard Parts: finding the appropriate service granularity and determining the correct communication styles between services. This talk introduces a new technique for performing tradeoff analysis for microservices architectures around both static and dynamic coupling. Static coupling helps determine the proper granularity by applying integrators and disintegrators. Dynamic coupling helps architects understand the interplay between communication (synchronous versus asynchronous), consistency (atomic versus eventual), and coordination (orchestration versus choreography), along with guidelines on when to choose particular communication styles. In this talk, Neal provides architects with the nomenclature and patterns to understand these difficult aspects of microservices and related architectures.

Architecture Distributed Systems Microservices Video

 Cell-Based Architecture — Architecture Pattern

Cell-based architecture in computing involves designing systems that consist of interconnected cells, each cell capable of executing tasks independently. Like the cells in a biological organism, these computing cells have their own processing units, memory, and communication capabilities. They operate in parallel, exchanging information and collaborating to solve complex problems efficiently.

Architecture Design

 An Introduction to Residuality Theory

Residuality theory is a revolutionary new theory of software design that aims to make it easier to design software systems for complex business environments. Residuality theory models software systems as interconnected residues - an alternative to component and process modeling that uses applied complexity science to make managing uncertainty a fundamental part of the design process.

Architecture Design

 How to design software architecture: Top tips and best practices

You wouldn’t want to jump into a project without a solid plan, and software architecture design is no different. By making this process more effective, you can account for all of your requirements properly and give stakeholders the opportunity to provide their input.\n\nUsing technical visuals and a careful planning process, you can outline your software architecture and design before you get started on a prototype.

Architecture Design

 I Made Everything Loosely Coupled. Does My App Fall Apart?

Integrating systems provides many benefits, from seamless user experiences, consolidated data for better insights, or interacting with partner ecosystems. And the modern cloud applications that we are building are fine-grained and thus inherently interconnected. Despite having connected systems for decades, some of the fundamental concepts of partial failure, eventual consistency, or idempotency still challenge many developers.\n\nThis session tackles the nuances of integrated systems, such as messages vs. events, thinking in integration patterns, whether loose coupling is always better, and how cloud automation can change the way you think about integration.

Architecture Microservices Video