> ## Content Index
> Fetch the complete content index at: https://www.antoinebuteau.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Lessons from John Ousterhout
- URL: https://www.antoinebuteau.com/lessons-from-john-ousterhout/
- Published: 2026-05-29T01:35:40.000Z
- Updated: 2026-07-18T21:58:03.000Z
- Description: John Ousterhout, a Stanford professor and creator of Tcl, argues that managing complexity is engineering’s hardest problem. His work on Raft and A Philosophy of Software Design offers practical principles for building systems that remain understandable and maintainable.
- Author: Antoine Buteau
- Tags: Profile, Science & Technology Thinkers Profiles

![Visual summary of operating lessons from John Ousterhout.](https://www.antoinebuteau.com/content/images/2026/05/lessons-from-john-ousterhout-profile-infographic.webp)

## Lessons from John Ousterhout

John Ousterhout, a Stanford professor and creator of Tcl, argues that the hardest part of engineering is simply managing complexity. From his work on the Raft algorithm to his book *A Philosophy of Software Design*, he provides a practical manual for building systems that stay maintainable.

### Part 1: The Nature of Complexity

1. **On the Definition of Complexity:** "Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system." — [*Source: A Philosophy of Software Design (Book)*](https://web.stanford.edu/~ouster/cgi-bin/book.php?ref=antoinebuteau.com)
2. **On Change Amplification:** Complexity is present when a seemingly simple change requires modifications in many different places across the codebase. — [*Source: Stanford CS 190 Lecture*](https://web.stanford.edu/~ouster/cgi-bin/cs190-spring18/index.php?ref=antoinebuteau.com)
3. **On Cognitive Load:** High complexity forces a developer to keep too much information in their head at once to complete a single task. — [*Source: Software Engineering Radio Ep. 520*](https://www.se-radio.net/2022/08/episode-520-john-ousterhout-on-a-philosophy-of-software-design/?ref=antoinebuteau.com)
4. **On Unknown Unknowns:** The worst symptom of complexity is not knowing what parts of the code must be modified or what information is needed to perform a task safely. — [*Source: Medium - Complexity in Software Design*](https://medium.com/@p%5Fp%5Fp/summary-a-philosophy-of-software-design-6f77755353d?ref=antoinebuteau.com)
5. **On Complexity Accumulation:** "Complexity isn't caused by a single catastrophic error; it accumulates in lots of small chunks." — [*Source: Google Tech Talk - A Philosophy of Software Design*](https://www.youtube.com/watch?v=bmSAYlu0NcY&ref=antoinebuteau.com)
6. **On Dependencies:** Complexity is born when code cannot be understood or modified in isolation; every dependency adds a potential path for complexity to travel. — [*Source: Pragmatic Engineer Interview*](https://blog.pragmaticengineer.com/a-philosophy-of-software-design-review/?ref=antoinebuteau.com)
7. **On Obscurity:** Complexity occurs when important information is not obvious, such as a variable name that doesn't reflect its purpose or a hidden side effect in a function. — [*Source: A Philosophy of Software Design (Book)*](https://web.stanford.edu/~ouster/cgi-bin/book.php?ref=antoinebuteau.com)
8. **On Zero Tolerance:** To slow the growth of complexity, engineers must adopt a zero-tolerance philosophy where every change is scrutinized for its impact on the system's clarity. — [*Source: Book Overflow Podcast*](https://www.youtube.com/watch?v=XvMshvVjO8s&ref=antoinebuteau.com)
9. **On the Cognitive Limit:** "The greatest limitation in writing software is our ability to understand the systems we are creating." — [*Source: Stanford Faculty Profile*](https://profiles.stanford.edu/john-ousterhout?ref=antoinebuteau.com)

### Part 2: Module Design and Abstraction

1. **On Deep Modules:** The best modules provide powerful functionality through a very simple interface, hiding significant internal complexity from the user. — [*Source: Google Tech Talk*](https://www.youtube.com/watch?v=bmSAYlu0NcY&ref=antoinebuteau.com)
2. **On Shallow Modules:** A shallow module has a complex interface relative to the small amount of functionality it provides, increasing the total complexity of the system without enough benefit. — [*Source: A Philosophy of Software Design (Book)*](https://web.stanford.edu/~ouster/cgi-bin/book.php?ref=antoinebuteau.com)
3. **On Information Hiding:** "It is more important for a module to have a simple interface than a simple implementation." — [*Source: Stanford CS 190 Design Principles*](https://web.stanford.edu/~ouster/cgi-bin/cs190-spring18/lecture.php?topic=modules&ref=antoinebuteau.com)
4. **On the Unix File I/O Example:** The Unix \`open\`, \`read\`, and \`write\` calls are classic deep modules because they hide thousands of lines of disk management and caching logic behind five simple parameters. — [*Source: Software Engineering Radio*](https://www.se-radio.net/2022/08/episode-520-john-ousterhout-on-a-philosophy-of-software-design/?ref=antoinebuteau.com)
5. **On Information Leakage:** Information leaks when a design decision is reflected in multiple modules, forcing a developer to change all of them if that decision is ever reversed. — [*Source: Medium - Information Hiding*](https://medium.com/@niklasdonges/a-philosophy-of-software-design-summary-6f8e7f1a3e6a?ref=antoinebuteau.com)
6. **On Pulling Complexity Downwards:** It is better for a module to be complex internally than to force its users to deal with that complexity; developers should suffer so their users don't have to. — [*Source: A Philosophy of Software Design (Book)*](https://web.stanford.edu/~ouster/cgi-bin/book.php?ref=antoinebuteau.com)
7. **On Classitis:** The "Clean Code" trend of creating many tiny classes often leads to shallow modules and "classitis," where the logic of a single task is fragmented across dozens of files. — [*Source: Book Overflow Podcast*](https://www.youtube.com/watch?v=XvMshvVjO8s&ref=antoinebuteau.com)
8. **On Interface Simplicity:** An interface should be designed to make the most common tasks as easy as possible while still allowing for more complex use cases. — [*Source: Google Tech Talk*](https://www.youtube.com/watch?v=bmSAYlu0NcY&ref=antoinebuteau.com)
9. **On General-Purpose vs. Special-Purpose:** Modules should be slightly more general-purpose than what is currently needed; this usually leads to cleaner abstractions and better information hiding. — [*Source: Stanford CS 190*](https://web.stanford.edu/~ouster/cgi-bin/cs190-spring18/lecture.php?topic=modules&ref=antoinebuteau.com)
10. **On Hidden State:** Abstractions fail when the user has to understand the internal state of a module to use its public methods correctly. — [*Source: A Philosophy of Software Design (Book)*](https://web.stanford.edu/~ouster/cgi-bin/book.php?ref=antoinebuteau.com)

### Part 3: Strategic vs. Tactical Programming

1. **On Working Code:** "The first step towards becoming a good software designer is to realize that working code isn't enough." — [*Source: A Philosophy of Software Design (Book)*](https://web.stanford.edu/~ouster/cgi-bin/book.php?ref=antoinebuteau.com)
2. **On the Tactical Tornado:** A tactical tornado is a prolific programmer who pumps out features quickly but leaves a trail of complexity that slows down the entire organization later. — [*Source: Medium - Tactical Tornadoes*](https://medium.com/@henrikwarne/a-philosophy-of-software-design-review-626a4574786d?ref=antoinebuteau.com)
3. **On Strategic Programming:** The primary goal of a strategic programmer is a great design; working code is merely a byproduct of that design process. — [*Source: Stanford CS 190*](https://web.stanford.edu/~ouster/cgi-bin/cs190-spring18/lecture.php?topic=tactical&ref=antoinebuteau.com)
4. **On the 10-20% Investment:** Engineers should spend 10–20% of their total development time on activities that don't directly implement features, such as design thinking and refactoring. — [*Source: Software Engineering Radio*](https://www.se-radio.net/2022/08/episode-520-john-ousterhout-on-a-philosophy-of-software-design/?ref=antoinebuteau.com)
5. **On Technical Debt:** Technical debt is the cumulative result of tactical decisions; eventually, the cost of adding new features becomes so high that the project grinds to a halt. — [*Source: Google Tech Talk*](https://www.youtube.com/watch?v=bmSAYlu0NcY&ref=antoinebuteau.com)
6. **On the "Hacker" Culture:** The industry often rewards tactical speed because it is visible, while ignoring the long-term value of strategic design because its benefits are invisible (avoided problems). — [*Source: Book Overflow Podcast*](https://www.youtube.com/watch?v=XvMshvVjO8s&ref=antoinebuteau.com)
7. **On Incremental Design:** Software design is never "done"; it must be an ongoing process where the system's structure is continuously refined as more is learned about the problem. — [*Source: A Philosophy of Software Design (Book)*](https://web.stanford.edu/~ouster/cgi-bin/book.php?ref=antoinebuteau.com)
8. **On Refactoring Costs:** It is much cheaper to fix a design flaw early than to wait until thousands of lines of code depend on a broken abstraction. — [*Source: Medium - Design Investment*](https://medium.com/@niklasdonges/a-philosophy-of-software-design-summary-6f8e7f1a3e6a?ref=antoinebuteau.com)
9. **On Design as a Skill:** Great design is not a talent one is born with; it is a skill that can be taught and learned through deliberate practice and critique. — [*Source: Stanford Faculty Profile*](https://profiles.stanford.edu/john-ousterhout?ref=antoinebuteau.com)

### Part 4: The Raft Consensus Algorithm

1. **On Designing for Humans:** The primary goal of Raft was to create a consensus algorithm that was easy for humans to understand, implement, and reason about. — [*Source: Raft Paper - In Search of an Understandable Consensus Algorithm*](https://raft.github.io/raft.pdf?ref=antoinebuteau.com)
2. **On the Failure of Paxos:** Paxos was so difficult to understand that most implementations were either incomplete or contained subtle bugs that compromised safety. — [*Source: Raft Website*](https://raft.github.io/?ref=antoinebuteau.com)
3. **On Understandability as a Metric:** "Understandability deserves more emphasis in algorithm design. Making a system simpler can have high impact." — [*Source: John Ousterhout's Stanford Page*](https://web.stanford.edu/~ouster/cgi-bin/home.php?ref=antoinebuteau.com)
4. **On Decomposition in Raft:** Raft achieved simplicity by decomposing the consensus problem into three independent subproblems: leader election, log replication, and safety. — [*Source: Raft Paper*](https://raft.github.io/raft.pdf?ref=antoinebuteau.com)
5. **On the Strong Leader Model:** By enforcing a strong leader who manages the entire log, Raft reduces the number of states the system can be in, making it easier to verify. — [*Source: Raft User Study Presentation*](https://www.youtube.com/watch?v=vYp4LYbnnW8&ref=antoinebuteau.com)
6. **On the Raft Name:** The name "Raft" is a play on the goal of creating something Reliable, And Fault-Tolerant, and a metaphor for "escaping the island of Paxos." — [*Source: Wikipedia - Raft (algorithm)*](https://en.wikipedia.org/wiki/Raft%5F%28algorithm%29?ref=antoinebuteau.com)
7. **On the User Study:** To prove Raft was more understandable, Ousterhout and Ongaro conducted a study with 43 students and showed they performed significantly better on Raft exams than Paxos exams. — [*Source: Raft Paper*](https://raft.github.io/raft.pdf?ref=antoinebuteau.com)
8. **On Practicality over Theory:** While Paxos is elegant in its mathematical minimalism, Raft is superior for engineering because it addresses practical needs like cluster membership changes. — [*Source: InfoQ - Raft vs Paxos*](https://www.infoq.com/articles/raft-consensus-algorithm/?ref=antoinebuteau.com)
9. **On Logic Separation:** Raft's design ensures that the safety logic is separate from the performance-optimizing logic, allowing engineers to tune the system without breaking its correctness. — [*Source: Raft Paper*](https://raft.github.io/raft.pdf?ref=antoinebuteau.com)

### Part 5: Tcl, Tk, and the Ousterhout Dichotomy

1. **On the Purpose of Tcl:** Tcl was designed as a "Tool Command Language"—a small, embeddable library that could give any C application a programmable interface. — [*Source: Tcl/Tk History*](https://www.tcl.tk/about/history.html?ref=antoinebuteau.com)
2. **On the Ousterhout Dichotomy:** Software development should be split into two layers: system programming (for performance/algorithms) and scripting (for gluing components together). — [*Source: Scripting: Higher-Level Programming for the 21st Century*](https://www.tcl.tk/doc/scripting.html?ref=antoinebuteau.com)
3. **On Glue Languages:** "System programming languages were designed for building data structures and algorithms from scratch... In contrast, scripting languages are designed for gluing." — [*Source: IEEE Computer - Scripting Paper*](https://ieeexplore.ieee.org/document/654787?ref=antoinebuteau.com)
4. **On Everything is a String:** Tcl's most famous design choice—treating every piece of data as a string—simplified the interface between the core C code and the scripting layer. — [*Source: Tcl/Tk History*](https://www.tcl.tk/about/history.html?ref=antoinebuteau.com)
5. **On the Birth of Tcl:** Ousterhout created Tcl in 1988 because he was tired of writing a new, mediocre command language for every interactive engineering tool he built. — [*Source: Stanford Tcl History*](https://web.stanford.edu/~ouster/cgi-bin/tclHistory.php?ref=antoinebuteau.com)
6. **On the Tk Toolkit:** Tk revolutionized GUI development by allowing developers to build professional interfaces with a few lines of script instead of thousands of lines of C++. — [*Source: ACM Software System Award Citation*](https://awards.acm.org/software-system?ref=antoinebuteau.com)
7. **On the "Two-Language" Benefit:** Using a scripting language for the UI and high-level logic allows for rapid prototyping and interactive development that is impossible in compiled languages. — [*Source: Scripting Paper*](https://www.tcl.tk/doc/scripting.html?ref=antoinebuteau.com)
8. **On Embeddability:** Tcl's design as a C library (rather than a standalone interpreter) was key to its early adoption in the EDA and CAD industries. — [*Source: Tcl/Tk History*](https://www.tcl.tk/about/history.html?ref=antoinebuteau.com)
9. **On Performance Trade-offs:** Scripting languages are slower than system languages, but for 80% of application code, developer productivity is more important than raw execution speed. — [*Source: Scripting Paper*](https://www.tcl.tk/doc/scripting.html?ref=antoinebuteau.com)

### Part 6: Operating Systems and High-Performance Storage

1. **On the Log-structured File System (LFS):** LFS was born from the insight that as RAM grew, almost all disk I/O would eventually be write-dominated because reads would hit the cache. — [*Source: The Design and Implementation of a Log-Structured File System*](https://dl.acm.org/doi/10.1145/121132.121137?ref=antoinebuteau.com)
2. **On Sequential Writing:** Traditional file systems were slowed down by disk seeks; LFS solved this by treating the entire disk as a single, append-only sequential log. — [*Source: Berkeley Sprite Project*](https://web.stanford.edu/~ouster/cgi-bin/home.php?ref=antoinebuteau.com)
3. **On the Segment Cleaner:** The greatest challenge in LFS was the "cleaner" process that had to reclaim space from old parts of the log without killing performance. — [*Source: LFS Paper*](https://dl.acm.org/doi/10.1145/121132.121137?ref=antoinebuteau.com)
4. **On Hardware/Software Symbiosis:** "The changed workloads require a write-optimized rather than read-optimized disk access technique." — [*Source: CMU Lecture on LFS*](https://www.cs.cmu.edu/~dga/15-440/S14/lectures/17-lfs.pdf?ref=antoinebuteau.com)
5. **On SSD Foundations:** Modern SSD controllers use a "Flash Translation Layer" that is effectively a log-structured file system because flash cannot be overwritten in place. — [*Source: Wikipedia - Log-structured file system*](https://en.wikipedia.org/wiki/Log-structured%5Ffile%5Fsystem?ref=antoinebuteau.com)
6. **On Sprite OS:** The Sprite operating system's core philosophy was to integrate networking into the kernel so thoroughly that a cluster appeared as a single time-sharing system. — [*Source: Sprite OS Paper*](https://dl.acm.org/doi/10.1145/128730.128731?ref=antoinebuteau.com)
7. **On Network Transparency:** In Sprite, a process could be migrated from one machine to another without the user or the application even noticing. — [*Source: Sprite Project History*](https://web.stanford.edu/~ouster/cgi-bin/home.php?ref=antoinebuteau.com)
8. **On Caching Strategy:** Sprite relied on large, variable-sized caches to minimize network traffic, a strategy that anticipated the massive increase in RAM sizes of the 1990s. — [*Source: Sprite OS Design Principles*](https://web.stanford.edu/~ouster/cgi-bin/home.php?ref=antoinebuteau.com)
9. **On the "Write-Back" Risk:** LFS and Sprite demonstrated that while "write-back" caches are dangerous for data integrity, they are the only way to achieve high performance on mechanical disks. — [*Source: LFS Paper*](https://dl.acm.org/doi/10.1145/121132.121137?ref=antoinebuteau.com)

### Part 7: The Design Process and Engineering Mindset

1. **On Design it Twice:** "Designing software is hard, so it's unlikely that your first thoughts... will produce the best design. Design it twice." — [*Source: A Philosophy of Software Design (Book)*](https://web.stanford.edu/~ouster/cgi-bin/book.php?ref=antoinebuteau.com)
2. **On Defining Errors Out of Existence:** Instead of throwing exceptions for edge cases, design the interface so the "common case" behavior naturally handles those situations correctly. — [*Source: Software Engineering Radio*](https://www.se-radio.net/2022/08/episode-520-john-ousterhout-on-a-philosophy-of-software-design/?ref=antoinebuteau.com)
3. **On the Substring Example:** A substring function should return an empty string if the range is invalid, rather than throwing an error; this simplifies the caller's logic. — [*Source: Google Tech Talk*](https://www.youtube.com/watch?v=bmSAYlu0NcY&ref=antoinebuteau.com)
4. **On White-Box Testing:** Ousterhout prefers writing tests while looking at the code to ensure every branch and control structure is exercised, rather than just testing the public API. — [*Source: Stanford CS 190 Unit Testing*](https://web.stanford.edu/~ouster/cgi-bin/cs190-spring18/lecture.php?topic=testing&ref=antoinebuteau.com)
5. **On the Failure of TDD:** "Test-Driven Development encourages a tactical mindset where you focus on passing the next test rather than thinking about the overall architecture." — [*Source: Book Overflow Podcast*](https://www.youtube.com/watch?v=XvMshvVjO8s&ref=antoinebuteau.com)
6. **On When TDD Works:** Writing the test first is only the superior approach when fixing a bug, as it ensures the bug is reproducible and the fix is verified. — [*Source: Pragmatic Engineer Interview*](https://blog.pragmaticengineer.com/a-philosophy-of-software-design-review/?ref=antoinebuteau.com)
7. **On Comments as Abstractions:** Comments should describe things that cannot be seen in the code, such as the *intent* behind a design or the *abstraction* being used. — [*Source: A Philosophy of Software Design (Book)*](https://web.stanford.edu/~ouster/cgi-bin/book.php?ref=antoinebuteau.com)
8. **On Meaningful Naming:** If you cannot find a clear, concise name for a module or variable, it is often a sign that the underlying design is fragmented or confusing. — [*Source: Medium - Software Design Principles*](https://medium.com/@niklasdonges/a-philosophy-of-software-design-summary-6f8e7f1a3e6a?ref=antoinebuteau.com)
9. **On Performance Intuition:** "Before making any changes, measure the system's existing behavior... changes based on intuition waste time on things that don't improve performance." — [*Source: A Philosophy of Software Design (Book)*](https://web.stanford.edu/~ouster/cgi-bin/book.php?ref=antoinebuteau.com)
10. **On the "Not Obvious" Rule:** "If a reader thinks it's not obvious, then it's not obvious. Instead of arguing, try to understand what they found confusing." — [*Source: Google Tech Talk*](https://www.youtube.com/watch?v=bmSAYlu0NcY&ref=antoinebuteau.com)

### Part 8: Career, Education, and the Future of Design

1. **On the ACM Software System Award:** Ousterhout received this award in 1997 for Tcl/Tk, joining the ranks of the creators of Unix, TCP/IP, and the World Wide Web. — [*Source: ACM Awards*](https://awards.acm.org/software-system?ref=antoinebuteau.com)
2. **On the Sun Microsystems Years:** Ousterhout spent four years at Sun Labs, where he led the SunScript team to turn Tcl into a cross-platform standard. — [*Source: Stanford Faculty Profile*](https://profiles.stanford.edu/john-ousterhout?ref=antoinebuteau.com)
3. **On Founding Scriptics:** In 1998, he founded Scriptics to provide commercial support for Tcl, eventually pivoting the company to XML-based B2B servers (Ajuba Solutions). — [*Source: Tcl/Tk History*](https://www.tcl.tk/about/history.html?ref=antoinebuteau.com)
4. **On Teaching at Stanford:** Ousterhout returned to academia in 2008 to teach CS 190, a course designed specifically to teach students how to manage complexity in large systems. — [*Source: Stanford CS 190 Course Page*](https://web.stanford.edu/~ouster/cgi-bin/cs190-spring18/index.php?ref=antoinebuteau.com)
5. **On AI and Design:** As AI tools become better at generating low-level code, the human engineer's role will shift almost entirely to high-level architectural design. — [*Source: Pragmatic Engineer - AI and Software Design*](https://blog.pragmaticengineer.com/a-philosophy-of-software-design-review/?ref=antoinebuteau.com)
6. **On AI's Design Dependency:** AI performs significantly better on well-designed, modular codebases; bad design now has a "multiplier" cost because it breaks AI assistance. — [*Source: Software Engineering Radio*](https://www.se-radio.net/2022/08/episode-520-john-ousterhout-on-a-philosophy-of-software-design/?ref=antoinebuteau.com)
7. **On the "Benevolent Dictator" Model:** Ousterhout led the Tcl community for over a decade before handing over governance to the Tcl Core Team in 2000\. — [*Source: Tcl Core Team History*](https://www.tcl.tk/about/tct.html?ref=antoinebuteau.com)
8. **On the Greatest Performance Improvement:** "The greatest performance improvement of all is when a system goes from not-working to working." — [*Source: Ousterhout's Stanford Page*](https://web.stanford.edu/~ouster/cgi-bin/home.php?ref=antoinebuteau.com)
9. **On Code as Documentation:** Ousterhout disagrees that "tests are the best documentation," arguing they are too verbose and spread out to explain a system's core abstractions. — [*Source: A Philosophy of Software Design (Book)*](https://web.stanford.edu/~ouster/cgi-bin/book.php?ref=antoinebuteau.com)
10. **On the Enduring Value of Design:** Despite rapid changes in languages and frameworks, the fundamental principles of complexity management remain the most stable knowledge in a developer's career. — [*Source: Stanford CS 190 Final Lecture*](https://web.stanford.edu/~ouster/cgi-bin/cs190-spring18/index.php?ref=antoinebuteau.com)