The Philosophy of Software Design – with John Ousterhout

Brought to by:

—
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!

—
The Pragmatic Engineer deepdives relevant for this episode:

—
Where to find John Ousterhout:

Where to find Gergely Orosz:

—
In this episode, we cover:

(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

—

—

[aoliveiragomes]

I've never seen anyone think so deeply at this level of abstraction about software. The best podcast on software engineering I've watched in years.

[dmgithinji]

"Education is about creating a safe space where people can make mistakes and learn from them" - this podcast is a real gem.

Just throwing this out there, but would some of those design lessons ever be shared online? Would be nice if this knowledge wasn't limited to your direct students.

[jchantrell]

This was one of the best podcasts/talks I've listened to about software in general. I'll be honest that when it ended I felt like I could listen to an hour or two more. It would be great if you could get John back at some point in the future and dive deeper on things, go over different topics, etc.

[vampfoxilli]

Heard what I wanted in the first minute of this video.
The title qualified the content, the hook satisfied the promise and i left it playing because I felt "like I just had to"
What i mean is...
Great video man!

[muesique]

Tcl: one of the most underrated languages. It's so logical and simple. You can be so productive. It's a multifunctional tool which can be extended endlessly.
I wished more will recognize it in the future.

[mthoncube]

This talk offers rare and insightful perspectives, showcasing exceptional depth and breadth in software design. I especially appreciated his perspective on AI-assisted coding, which added a thoughtful layer to the discussion.

[carl]

If you haven't read this book you need to. I don't think most software engineers have realised they've never studied software design (except in the standard Clean Code-ish advice that is industry lore). It's really the art of creating maintainability - via controlling the inevitable complexity you get as projects scale.

[michael_adisa]

In the middle of building my most complex software system ever, and this was perfect.

Thank you Gergely.

[nikkehtine]

It feels good to finally listen to someone who knows what they're talking about instead of "tech gurus" and hot takes on Twitter

[RobertSmith-lhhg]

Just want to say, this strikes so many nerves for me, and absolutely rings true.

I've recently architected a full stack enterprise app with many specific domain needs solo as a new grad.

This really puts to words a lot of things I had to stop and find what I think is a good balance for everything covered in this talk.

Amazing timing and relevance to what I'm working on daily.

100% grabbing the book because a design specific course was not available during my program.

[sisisisi]

This episode was in my feed & I’m glad I hit play.! I throughly enjoyed the entire episode and found it insightful. Gained a subscriber

[Technocyra]

Excellent video! As a student of Software Analysis and Development, I find it very valuable to have these software design principles discussed. The experience and holistic view of the subject shared by Prof. Ousterhout are very enriching and applicable to my field of study. thanks for sharing this content!

[StreetsOfBoston]

1:00:15
It's a bit of an art to get the balance of high Coherence and low Coupling right.
It can be tricky to figure what things are related and belong together and have autonomy, and what things are just dependencies.

[ChrisJackson-jsrd]

design is the process of taking a set of basic tools and capabilities + a problem you would like to solve = and determining the "best" way to apply those tools to that problem such that users no longer even recognize it as a problem

there are a million ways to skin a cat... doing it in a way that the cat is unaware .... to do this you need design

[categoric-ally]

I read the book The Philosophy of Software Design once every few months. Such a great way to think about software!

[bill_codes]

This was a great talk John is a great speaker and I found it comforting hearing his perspective as a self taught solo developer it can be hard to gauge our practice but I agree with John on all aspects really and found his perspective quite insightful. It's easy to get caught up in complexity and stop paying much mind to the philosophy of the design. Though again as a solo developer I think your philosophy naturally expresses itself but I can imagine that's much more chaotic in groups.

[brownhorsesoftware]

EXCELLENT!! Handle errors don't throw them! Every minute of this talk is highly valuable. Design is organization. A well designed error handling system is delightful! ❤

[jimxu]

Omg, every single philosophical thinking that Prof. John stated aligns with my view. I am grateful that someone in the industry is still thinking this way... Thank you for this interview.

[smallsnippets]

John Ousterhout might consider to write his next book about teaching Software Design, or maybe teaching teachers how to teach it.

[thebehavioral]

I think software design patterns and approaches are discussed less often because 1/ more design decisions are made for us and 2/ we're designing smaller systems and the implications of those design decisions don't extend very far.

1/ Frameworks are much more ubiquitous and deep than they were 20y ago. Today, developers may be leveraging decorators, visitors, dependency injection, etc. but only because their chosen framework has these patterns built in. Nothing wrong with this, it's just that developers don't have to make a choice.

2/ Microservices mean designs are inherently smaller and that's lowered the stakes for software designers. That's one of the primary appeals of the microservices approach.