References

Complexity is the single greatest constraint on software development over a system's lifetime. The job of design is to manage complexity, and the most powerful lever is modular design: split the system into modules whose interfaces are far simpler than their implementations, s...

Software delivery performance can be measured, it predicts organizational performance, and it is driven by specific capabilities a team can adopt. The headline result, established through survey research and statistical analysis rather than anecdote, is that speed and stabilit...

Data systems are built from a small set of foundational ideas, and every design is a tradeoff. The job is not to find the single best technology but to understand the guarantees a system does and does not provide, reason explicitly about reliability, scalability, and maintaina...

The hard part of most software is the complexity of the domain, not the technology. The way to manage it is to build a rigorous model of the domain, bind that model tightly to the code, and express it in a single shared language used by developers and domain experts alike. At...

Software architecture has no universal best practices, only tradeoffs in context. An architect's job is to identify the architecture characteristics (the " ilities") that matter for a given system, choose a structure that best supports the most important ones, knowing every ch...

Failure in complex systems is normal, multi causal, and systemic. Such systems are intrinsically hazardous and are held back from catastrophe only by multiple overlapping defenses, so they run continuously in a degraded state full of latent flaws. Catastrophe happens when seve...

People are not the fully rational "Econs" of economic theory but "Humans" with bounded rationality, predictable biases, and limited self control. Because every choice is presented in some context, there is no neutral way to design that context: the person who arranges the opti...

Complexity is the single greatest difficulty in building and maintaining large software, and most of it is accidental, introduced by us, rather than essential to the problem. The two largest sources of accidental complexity are mutable state and control flow. The paper argues...

The design of existing code can be improved continuously through small, behavior preserving transformations. Good internal structure is what keeps software cheap to change; refactoring is the disciplined, everyday practice that maintains that structure as understanding grows,...

Reliability is the most important feature of any system, but more reliability is not always better: there is an optimal point past which chasing nines costs more than it returns. Treat operations as an engineering and software problem. Choose an explicit reliability target, me...

Teams, not individuals, are the fundamental unit of software delivery, and team structure should be designed deliberately to enable fast flow of change. Because organizations produce systems that mirror their communication structure (Conway's Law), shaping teams and their inte...

Usability is a property of design, not of the people who struggle with a thing. When everyday objects and systems are hard to use, the fault lies in a design that fails to communicate what is possible and what just happened. Good design makes the right actions discoverable and...

A system exists to achieve a goal, and for a business that goal is to make money, measured as throughput (the rate of generating money through sales) against inventory and operating expense. The output of the whole system is governed not by the capacity of its parts but by its...

Large software projects fail in characteristic, recurring ways rooted in people and communication, not just technology. Effort and progress are not interchangeable: adding people to a late project makes it later, because work has sequential constraints and communication overhe...

Good software comes from a set of pragmatic, craft level habits applied continuously rather than from any single methodology. The two foundations are DRY (every piece of knowledge has one authoritative representation) and orthogonality (components are independent, so change st...

A system is a set of elements interconnected so as to produce a pattern of behavior over time, and that behavior is generated by the system's own structure, not by external events or the people in it. The fundamental building blocks are stocks (accumulations) and the flows tha...

The mind runs on two systems: a fast, automatic, intuitive System 1 that generates impressions effortlessly, and a slow, deliberate, effortful System 2 that can reason but is lazy and usually defers to System 1. Most judgment originates in System 1, which answers hard question...

Security is something you reason about and design in, not a feature you add later. The way to do it is structured, not heroic: anyone can find what can go wrong with a system by working through a small set of questions and structured enumerations, rather than relying on the in...

Durable results come from culture and repeatable processes, not heroics or good intentions. The central practice is to work backward from the customer: define the desired customer experience first and reason back to what to build, rather than starting from what is easy to buil...