FrameworkContrarian viewSoftware engineering
Complexity is what you must hold in your head to make a safe change
John Ousterhout · A Philosophy of Software Design
The idea
Ousterhout defines complexity in software as whatever makes a system hard to understand and modify, and argues that most of it comes from dependencies and obscurity rather than from size. His prescription disagrees with a lot of received advice: deep modules, which hide a lot of functionality behind a small interface, beat many small shallow ones, because each interface is something a reader has to hold in mind. The disagreement is useful in itself. An engineer who can say why small functions are not always better has understood the goal, which is reducing what a change requires you to know.
Judge a design by how much a reader must understand to change it safely, and prefer deep modules behind small interfaces.
When it works
Code review, design discussions, and software engineering interviews that ask what good code is.
When it may fail
Deep modules can hide too much, and the right depth depends on how often the inside changes. The book is a position in an argument, which is exactly why it is worth reading.
How to use it
In a review, ask for each interface what a caller must know to use it correctly. An interface that leaks its implementation is shallow however short it is, and merging two shallow modules into one deep one is often the right fix.
Where it came from
Book A Philosophy of Software Design · John Ousterhout
What the source says. A short argument about deep modules and shallow interfaces that disagrees, usefully, with a lot of received advice about small functions.
Connected ideas
Says something similar
Speed and stability rise together. The trade-off is the mythThe practices that make shipping frequent are the ones that make it safe, so do not trade one for the other.
Concepts
Put it to work on L3VLUP
More like this
- TechniqueSoftware engineeringVideo located
An index turns a table scan into a handful of page reads, paid for in write speed and disk
An index buys read speed with write speed and disk; add one for the query you run most and remove the ones you never use.
From B-tree vs B+ tree in Database Systems · Hussein Nasser
- FrameworkSoftware engineeringVideo located
Consensus is agreeing on one value when any machine may crash and the network may lie
Ask what a consensus protocol assumes about crashes and the network; its guarantee is only as strong as those assumptions.
From Distributed Systems 6.1: Consensus · Martin Kleppmann (Cambridge)
- TechniqueSoftware engineeringVideo located
In a distributed system every request may arrive twice, so make the second one harmless
Design every retryable operation so that doing it twice has the same effect as doing it once; the network will test this for you.
From Build a Robust Payments Service Using Idempotency Keys · Arpit Bhayani
- FrameworkArtificial intelligenceVideo located
The context window is not the constraint people think it is; attention across it is
A long window degrades before it fills; curate and order what goes in rather than relying on size.
From Why LLMs Get Dumb (Context Windows Explained) · NetworkChuck