The Philosophy of Software Design – with John Ousterhout

Supported by Our Partners

•⁠ CodeRabbit⁠⁠ — Cut code review time and bugs in half. Use the code PRAGMATIC to get one month free.

•⁠ Modal⁠ — The cloud platform for building AI applications.

—

How will AI tools change software engineering? Tools like Cursor, Windsurf and Copilot are getting better at autocomplete, generating tests and documentation. But what is changing, when it comes to software design?

Stanford professor John Ousterhout thinks not much. In fact, he believes that great software design is becoming even more important as AI tools become more capable in generating code. 

In this episode of The Pragmatic Engineer, John joins me to talk about why design still matters and how most teams struggle to get it right. We dive into his book A Philosophy of Software Design, unpack the difference between top-down and bottom-up approaches, and explore why some popular advice, like writing short methods or relying heavily on TDD, does not hold up, according to John.

We also explore: 

• The differences between working in industry vs. academia 

• Why John believes software design will become more important as AI capabilities expand

• The top-down and bottoms-up design approaches – and why you should use both

• John’s “design it twice” principle

• Why deep modules are essential for good software design 

• Best practices for special cases and exceptions

• The undervalued trait of empathy in design thinking

• Why John advocates for doing some design upfront

• John’s criticisms of the single-responsibility principle, TDD, and why he’s a fan of well-written comments 

• And much more!

As a fun fact: when we recorded this podcast, John was busy contributing to the Linux kernel: adding support to the Homa Transport Protocol – a protocol invented by one of his PhD students. John wanted to make this protocol available more widely, and is putting in the work to do so. What a legend! (We previously covered how Linux is built and how to contribute to the Linux kernel)

—

Timestamps

(00:00) Intro 

(02:00) Why John transitioned back to academia

(03:47) Working in academia vs. industry 

(07:20) Tactical tornadoes vs. 10x engineers

(11:59) Long-term impact of AI-assisted coding

(14:24) An overview of software design

(15:28) Why TDD and Design Patterns are less popular now 

(17:04) Two general approaches to designing software 

(18:56) Two ways to deal with complexity 

(19:56) A case for not going with your first idea 

(23:24) How Uber used design docs

(26:44) Deep modules vs. shallow modules

(28:25) Best practices for error handling

(33:31) The role of empathy in the design process

(36:15) How John uses design reviews 

(38:10) The value of in-person planning and using old-school whiteboards 

(39:50) Leading a planning argument session and the places it works best

(42:20) The value of doing some design upfront 

(46:12) Why John wrote A Philosophy of Software of Design 

(48:40) An overview of John’s class at Stanford

(52:20) A tough learning from early in Gergely’s career 

(55:48) Why John disagrees with Robert Martin on short methods

(1:10:40) John’s current coding project in the Linux Kernel 

(1:14:13) Updates to A Philosophy of Software Design in the second edition

(1:19:12) Rapid fire round

(1:01:08) John’s criticisms of TDD and what he favors instead 

(1:05:30) Why John supports the use of comments and how to use them correctly

(1:09:20) How John uses ChatGPT to help explain code in the Linux Kernel

—

The Pragmatic Engineer deepdives relevant for this episode:

• Engineering Planning with RFCs, Design Documents and ADRs

• Paying down tech debt

• Software architect archetypes

• Building Bluesky: a distributed social network

—

See the transcript and other references from the episode at ⁠⁠https://newsletter.pragmaticengineer.com/podcast⁠⁠

—

Production and marketing by ⁠⁠⁠⁠⁠⁠⁠⁠https://penname.co/⁠⁠⁠⁠⁠⁠⁠⁠. For inquiries about sponsoring the podcast, email podcast@pragmaticengineer.com.