Reading list

Other people have made the case for simplicity better than I can. These are the talks, essays, and books I keep sending to people.

Start here

• Simple Made Easy
  Rich Hickey · talk, 2011

  If you only watch one thing on this list, watch this. Hickey separates simple (one fold, not tangled) from easy (near at hand, familiar). Once you see the difference, you'll notice it in every design review.

• No Silver Bullet: Essence and Accident in Software Engineering
  Fred Brooks · essay, 1986

  Brooks splits complexity into the kind the problem brings (essential) and the kind we add ourselves (accidental). Forty years later it's still the most useful way to think about this.

• Choose Boring Technology
  Dan McKinley · essay, 2015 (slides)

  Every organization gets about three "innovation tokens." Spend them on what makes you different, not on a new database. This is the best argument I know for a deliberately small technology portfolio.

• A Philosophy of Software Design
  John Ousterhout · book

  A short, practical book about one goal: reducing complexity. "Deep modules," a simple interface over a powerful implementation, is an idea you'll keep coming back to.

Engineering

• Is High Quality Software Worth the Cost?
  Martin Fowler · essay

  Fowler argues that internal quality isn't a trade-off against speed. It's what makes speed possible. Good to hand to anyone who thinks quality is a luxury.

• Technical Debt Quadrant
  Martin Fowler · essay

  Not all technical debt is the same. A clear way to talk about which debt you took on deliberately and which you took on by accident.

• Tidy First?
  Kent Beck · book and newsletter

  Beck on when to clean up code before a change, after it, or not at all. It treats simplicity as an economic decision instead of a moral one.

• The Grug Brained Developer
  Carson Gross · essay

  "Complexity very, very bad." Funny, and deeper than it looks. Good for when you need to make the point without sounding preachy.

• Simplicity (Site Reliability Engineering, ch. 9)
  Google SRE team · book chapter

  Why reliability engineers count "boring" as a compliment, and why they treat every new line of code as a liability.

• Things You Should Never Do, Part I
  Joel Spolsky · essay, 2000

  The classic warning about the big rewrite. The urge to start over is real, and it usually costs more than the mess you're trying to escape.

Architecture

• The Software Architect Elevator
  Gregor Hohpe · book

  The best description I've found of what an enterprise architect is for: riding between the penthouse and the engine room so each understands the other. Read Clif's notes on it.

• Platform Strategy: Innovation Through Harmonization
  Gregor Hohpe · book

  How a well-built platform can standardize and speed teams up at the same time, and why most "platforms" are really just bundles of tools. Read Clif's notes on it.

• In Defense of Simple Architectures
  Dan Luu · essay

  A case study of a successful company running on a monolith and a database. Proof that "simple" scales further than people expect.

• Monolith First
  Martin Fowler · essay

  Why most successful microservice systems started as monoliths. Pair it with his Microservice Trade-Offs.

• Gall's Law
  John Gall · from Systemantics, 1975

  "A complex system that works is invariably found to have evolved from a simple system that worked." Worth memorizing.

• Documenting Architecture Decisions
  Michael Nygard · essay, 2011

  The original proposal for Architecture Decision Records: lightweight documentation that people actually read. See also adr.github.io.

• The C4 Model
  Simon Brown

  A simple, layered way to diagram software architecture. Most architecture diagrams are too complicated, and this is the fix.

• Building Evolutionary Architectures
  Neal Ford, Rebecca Parsons, Patrick Kua, Pramod Sadalage · book

  How to design for change instead of guessing the future, using "fitness functions" to keep an architecture honest.

• Consortium for Information & Software Quality (CISQ)
  Standards body

  Measurable software quality standards built on ISO/IEC 25010. Useful when you need to hold a vendor, or yourself, to an objective bar.

Leadership and organizations

• Team Topologies
  Matthew Skelton & Manuel Pais · book

  Your architecture will mirror your org chart (Conway's Law), so design both on purpose. Its idea of "cognitive load" as a limit on a team is one of the most useful in the field.

• An Elegant Puzzle: Systems of Engineering Management
  Will Larson · book

  Engineering management treated as a systems problem. His essays on migrations and staff engineering are excellent too.

• DORA research
  Nicole Forsgren, Jez Humble, Gene Kim, and the DORA team

  Years of evidence that small batches, simple pipelines, and loosely coupled systems beat the alternatives. The book is Accelerate.

• How Complex Systems Fail
  Richard Cook · essay, 1998

  Eighteen short points about failure in complex systems. Required reading before your next post-incident review.

• On Being a Senior Engineer
  John Allspaw · essay

  Seniority shows up as judgment, trade-off awareness, and making the people around you better, not as cleverness.

• Chesterton's Fence
  Farnam Street · essay

  A necessary counterweight. Before you remove something in the name of simplicity, find out why it's there.

• Shape Up
  Ryan Singer · free book

  Fixed time, variable scope. A product process built around cutting things, which is the hardest and most valuable skill a team can have.

Simplicity in the age of AI

• Building Effective Agents
  Anthropic · engineering essay

  The advice from people who build these systems: start with the simplest thing that works, and add complexity only when it clearly pays for itself.

• Simon Willison's Weblog
  Simon Willison · blog

  Practical, skeptical, hands-on writing about using AI tools in real engineering work without fooling yourself.

---

This list keeps growing. If you know something that belongs here, I’d like to hear about it.