Learning Software Architecture: Why Theory Alone Isn't Enough

If you've ever felt that software architecture books leave you unprepared for real-world systems, you're not alone. A recent blog post by matklad titled "Learning Software Architecture" struck a nerve on Hacker News, earning over 130 points and sparking a thoughtful discussion. The core message? Architecture isn't something you can learn from principles alone—you have to engage with real systems, make mistakes, and even subtract unnecessary complexity.

Why Theory Alone Isn't Enough for Software Architecture

The post argues that traditional approaches to learning software architecture—like reading design pattern catalogs or memorizing SOLID principles—often miss the mark. Instead, the author advocates for studying concrete systems: open-source projects, legacy codebases, and your own past projects. He suggests rewriting a project three times to explore different design trade-offs, and diving into the history of large codebases to understand how architectural decisions were shaped by constraints and changing visions.

The post also touches on the importance of subtraction: removing abstractions and ceremony that no longer serve a purpose. It points to resources like the Architecture of Open Source Applications (AOSA) books, where maintainers explain why their projects look the way they do.

HN Discussion Highlights the Need for Case Studies

The HN community resonated with the idea that architecture is learned through practice and reflection. One commenter drew a parallel with ancient Chinese philosophy:

"Confucius treats learning as cultivation: you do not really know something just because you were instructed in it. You know it by practicing, reflecting, making mistakes, and gradually developing judgment. Laozi gives the complementary warning: 'In pursuing learning, every day something is added. In pursuing the Tao, every day something is dropped.' Mastery is not only accumulation. It is also subtraction."

Another commenter pointed out a gap between general software development advice and architecture specifically:

"The recommendations are often very good... but seem to be on software development in general, not actually software architecture in particular."

Several commenters wished for more architecture case studies, especially for non-coders evaluating LLM system designs, and recommended the AOSA series as a model.

My View: Architecture Mastery Requires Practice and Subtraction

I think the post nails something fundamental: architecture is a craft, not a science. You can't learn it purely from books because every system exists in a context—business constraints, team size, technology evolution—that textbooks simplify away. The Confucius-and-Laozi analogy is apt: you need both accumulation (reading code, studying patterns) and subtraction (removing what no longer fits).

What's missing from many discussions is the emotional side. Architecture decisions are often political or driven by deadlines. The best designs account for human factors: how will this abstraction be understood by a new hire? How much complexity will the team tolerate? Learning architecture means learning to navigate those trade-offs, which only comes from experience.

I also agree that AOSA is a gem. Each chapter is a time capsule of decisions made under real pressures. Reading it alongside current open-source projects can show you how architecture evolves—and how early choices haunt maintainers years later.

Actionable Steps: Case Studies, Refactoring, and Subtraction

If you're serious about improving your architectural skills, here are concrete steps:

1. Study a legacy system. Pick an open-source project with a long history (e.g., Git, PostgreSQL, or a web framework you use). Trace a feature from its first commit to its current implementation. Note how the architecture changed and why.

2. Rewrite a project. Take a small project you've built and rewrite it from scratch three times, each time with a different architectural approach (e.g., monolithic, modular monolith, microservices). Pay attention to what gets easier and harder.

3. Practice subtraction. Look at your current codebase and ask: what abstractions can be removed without losing functionality? A single consistent pattern is often better than five clever ones.

Here's a trivial example of subtraction: replacing a complex strategy pattern with a simple if-else when the number of strategies is small and stable:

# Before: Strategy pattern with interface and registry
from abc import ABC, abstractmethod

class DiscountStrategy(ABC):
    @abstractmethod
    def apply(self, amount): ...

class NoDiscount(DiscountStrategy):
    def apply(self, amount): return amount

class TenPercentDiscount(DiscountStrategy):
    def apply(self, amount): return amount * 0.9

def get_discount(type: str) -> DiscountStrategy:
    strategies = {'none': NoDiscount(), '10%': TenPercentDiscount()}
    return strategies[type]

# After: Simple if-else, much easier to read
def apply_discount(amount: float, discount_type: str) -> float:
    if discount_type == '10%':
        return amount * 0.9
    return amount

This isn't always the right call, but it illustrates the subtractive mindset: start simple, add complexity only when you need it. The YAGNI principle and KISS principle complement this approach.

Who Should Invest in Learning Software Architecture?

Yes, if you're a developer who wants to move beyond writing code that works to designing systems that endure. No, if you're content with small, throwaway projects where architecture doesn't matter. For everyone else, the actionable takeaway is: learn by doing, study real code, and don't be afraid to delete your own abstractions.