Because code is invisible, software engineering in the large has become the hardest kind of engineering. We need powerful mechanisms to give our software structure and shape; this provides strong mind-sync among the software team and domain experts.

Just as industrial engineering influenced Agile/Scrum and civil engineering inspired the waterfall model, software engineering has drawn from other disciplines. But the unique nature of software demands a fundamentally different way of thinking.

Gang of Four design patterns are often overused and misapplied, leading to unnecessary complexity and poor abstraction. Avoid treating them as universal solutions; instead, focus on clarity, simplicity, and contextually appropriate design.

Agile methodologies, focusing primarily on delivering working code, inadvertently act as antipatterns when it comes to ensuring software quality and highly maintainable source code. This section distinguishes the Technical Wealth Method from standard Agile/Scrum philosophies.

There are two very distinct ways of developing software - prototype mode and sustained mode. You need to know where your development falls on the spectrum.

While the most mature engineering fields have progressively developed over the span of thousands of years, software engineering has only been practiced for around 65 years. Given the immaturity of this field, we should expect that even ideas that are widely accepted today may be proven to have unforeseen flaws that will lead to their decline in the future.

Mainstream software development advice is based on four commandments: Decoupling, Separation of Concerns, Information Hiding, and No Duplicated Code. These might be desirable, but they are the wrong fundamental principles of software development.

Robert Glass once said hype is the plague of software. This section explores how to critically assess trends and avoid chasing buzzwords that degrade engineering discipline.

Every line of code and test undergoes rigorous human review. This full-spectrum review process creates codebases that are both durable and high quality.

Great process doesn’t substitute for great skill. Becoming a master software designer requires ongoing practice, critique from experienced mentors, and exposure to real-world complexity.

Software architecture is the high level structural shape of a software system that once set is very difficult to drastically change and defines the mix of quality attributes that have been emphasized and de-emphasized. Since the best predictor of software project failure is size, good architecture is our primary tool to contain cognitive complexity as the codebase grows.

Through real-world examples, this section illustrates how poor architectural decisions in growing codebases can lead to severe productivity loss, failed projects, and full rewrites—while showing how thoughtful architecture can turn failure into long-term success.

Quality lives in the non-functional requirements—performance, usability, security, etc. These "ilities" aren't free; they come with substantial costs in design complexity, testing, and maintenance.

Quality attributes, not functionality, are the hard part of software. Engineering teams often focus purely on functional requirements and delay quality attribute testing until the architecture is already set and it’s too late.

You don't test quality in, you design it in. Don't be led astray by the hype of DevOps, Continuous Delivery, and Microservices.

Code reuse in the large refers to successfully fielding reusing large amounts of your existing code base to field new products in a fraction of the time that would be possible if you had to start from scratch. Our Durable Codebase has been the greatest single factor in us delivering sophisticated solutions fast without sacrificing high quality.

Our durable codebase is a massive collection of proven, well-tested modules. But a subtler kind of reuse of well written code is the ability to copy large chunks of high-quality code into new programs while making small tweaks throughout to fit different design goals.

Dive into the ideas of Christopher Alexander, whose work on architectural patterns inspired he Gang of Four’s design patterns. Understand what was lost—and what remains relevant.

Decisions at the system level set constraints on decisions at the process and class level. Thus, top-down design can set constraints on the software architecture in a good way. However, Bottom up design promoted by Agile is an anti-pattern for achieving conceptual integrity at the macro levels.

Software engineering today doens’t appreciate that software architecture is heavily influenced by early decisions and code rather than by the decisions and code written in the mid or late stages of a product development effort.

Good designs must be evaluated within the context and associated constraints. Once an architecture is in place, it becomes hard to change—so getting it right early is essential.

Complexity is the enemy. To manage large codebases, you must ruthlessly pursue simplicity in both design and implementation.

Quality attributes aren’t free. Over-pursuit of quality attributes results in a more complex, over-engineered, and less maintainable solution. Developers should count the complexity costs before adopting any idea that promotes gains in quality attributes.

When battling our #1 enemy of complexity, software must be designed for simplicity at the macro level before the micro level.

Breaking a large software application into many smaller pieces usually doesn’t create greater maintainability. Some modularization is necessary to achieve optimal maintainability, but over-modularization decreases maintainability.

Indirection adds complexity, and unnecessary use of indirection will just make it harder for maintenance programmers to see the big picture.

Practically all popular software design advice out there claims to help you yield more maintainable code, but this advice falls short. Such advice biases software practitioners into overly complex solutions which are harder to maintain than necessary.

Flexible software architectures are always more complex and awkward to maintain. Software developers should think harder about what you should omit rather than what additional things you should put in.

Great software designers create software optimized not for their own pleasure but for others’ comprehension. Creating intuitive designs requires empathy and humility.

Real-world objects provide objective, hard, black & white boundaries. A good abstraction should result in it being very obvious whether a particular method or data belongs in that class or not.

Designs from the ivory tower architect rarely work out, but neither do evolutionary designs. To have great designs you need to ride the elevator up and down.

Software maintenance tends to increase entropy, so to contain complexity you need to make concerted efforts to keep entropy down.

Severe underinvestment in code reviews and rigorous systematic testing leads many Agile projects into rapid accumulation of massive amounts of technical debt.