1 00:00:00,000 --> 00:00:04,000 A Philosophy of Software Design Part 2 - Working Code Is Not 2 00:00:04,000 --> 00:00:08,000 Enough A Philosophy of Software Design treats software design 3 00:00:08,000 --> 00:00:12,000 less as architectural theater and more as the daily work of 4 00:00:12,000 --> 00:00:13,000 managing complexity. 5 00:00:13,000 --> 00:00:17,000 This part covers Chapter 3 Working Code Isn't Enough and Chapter 6 00:00:17,000 --> 00:00:19,000 4 Modules Should Be Deep. 7 00:00:19,000 --> 00:00:23,000 It uses only short key phrases from the source and turns the 8 00:00:23,000 --> 00:00:26,000 reading into summary, interpretation, and application. 9 00:00:26,000 --> 00:00:30,000 The guiding question is: Where does quickly working code diverge 10 00:00:30,000 --> 00:00:33,000 from code that remains understandable tomorrow? 11 00:00:33,000 --> 00:00:37,000 How to use this note This is part 2 of a ten-part reading of A 12 00:00:37,000 --> 00:00:39,000 Philosophy of Software Design. 13 00:00:39,000 --> 00:00:43,000 The scope is Chapter 3 Working Code Isn't Enough and Chapter 4 14 00:00:43,000 --> 00:00:45,000 Modules Should Be Deep. 15 00:00:45,000 --> 00:00:49,000 The operating principle remains: book notes are storage; insight 16 00:00:49,000 --> 00:00:50,000 cards are currency. 17 00:00:50,000 --> 00:00:54,000 L0 · Entry Core sentence: Strategic programming treats future 18 00:00:54,000 --> 00:00:58,000 change cost as part of the design problem, not as a later 19 00:00:58,000 --> 00:00:59,000 cleanup task. 20 00:00:59,000 --> 00:01:03,000 Why read this: As AI tools and automation make code faster to 21 00:01:03,000 --> 00:01:07,000 produce, I want sharper standards for code that remains 22 00:01:07,000 --> 00:01:09,000 understandable and changeable. 23 00:01:09,000 --> 00:01:13,000 Initial hypothesis: In practice, working behavior can dominate 24 00:01:13,000 --> 00:01:14,000 design judgment. 25 00:01:14,000 --> 00:01:18,000 This range lowers working behavior to a minimum condition and 26 00:01:18,000 --> 00:01:21,000 treats deep modules as units of long-term investment. 27 00:01:21,000 --> 00:01:25,000 Author context: John Ousterhout is a computer scientist known 28 00:01:25,000 --> 00:01:29,000 for work in operating systems, distributed systems, Tcl/Tk, and 29 00:01:29,000 --> 00:01:32,000 software design education at Stanford. 30 00:01:32,000 --> 00:01:36,000 Scope: Chapter 3 Working Code Isn't Enough and Chapter 4 Modules 31 00:01:36,000 --> 00:01:40,000 Should Be Deep L1 · Captures Short phrase · design "tactical 32 00:01:40,000 --> 00:01:44,000 programming" This names the habit of solving only the immediate 33 00:01:44,000 --> 00:01:45,000 problem. 34 00:01:45,000 --> 00:01:49,000 Fast local fixes can slowly make the structure slower to change. 35 00:01:49,000 --> 00:01:54,000 Short phrase · design "strategic programming" This treats future 36 00:01:54,000 --> 00:01:56,000 change cost as part of today's work. 37 00:01:56,000 --> 00:02:00,000 The habit needed here is small recurring design investment. 38 00:02:00,000 --> 00:02:04,000 Short phrase · design "deep modules" This describes a module 39 00:02:04,000 --> 00:02:07,000 with a simple interface and substantial hidden capability. 40 00:02:07,000 --> 00:02:11,000 The useful measure is not class count but functionality per 41 00:02:11,000 --> 00:02:12,000 interface burden. 42 00:02:12,000 --> 00:02:16,000 Copyright boundary This public note does not reproduce long 43 00:02:16,000 --> 00:02:17,000 source passages. 44 00:02:17,000 --> 00:02:21,000 It uses chapter-level concepts and short phrases as anchors, 45 00:02:21,000 --> 00:02:25,000 then provides transformative summary and commentary. 46 00:02:25,000 --> 00:02:28,000 L2 · Map Range Summary Main claim --- ------ --------- 47 00:02:28,000 --> 00:02:32,000 ------------ 1 Tactical programming Prioritizes getting behavior 48 00:02:32,000 --> 00:02:36,000 to work while delaying structural cost Completion may be fast 49 00:02:36,000 --> 00:02:40,000 while future change becomes slow 2 Strategic programming Adds 50 00:02:40,000 --> 00:02:44,000 small design investments consistently Design is a daily choice 51 00:02:44,000 --> 00:02:48,000 rather than a later rewrite 3 Module interface Reduces the 52 00:02:48,000 --> 00:02:52,000 surface users must understand A simpler interface lowers memory 53 00:02:52,000 --> 00:02:56,000 burden 4 Deep modules Provide large functionality behind a small 54 00:02:56,000 --> 00:03:01,000 interface Good abstractions absorb internal complexity 5 Shallow 55 00:03:01,000 --> 00:03:05,000 modules Split code without reducing user burden Division alone 56 00:03:05,000 --> 00:03:09,000 does not guarantee design quality Argument in one paragraph: 57 00:03:09,000 --> 00:03:13,000 Strategic programming treats future change cost as part of the 58 00:03:13,000 --> 00:03:15,000 design problem, not as a later cleanup task. 59 00:03:15,000 --> 00:03:19,000 In practice, working behavior can dominate design judgment. 60 00:03:19,000 --> 00:03:23,000 This range lowers working behavior to a minimum condition and 61 00:03:23,000 --> 00:03:27,000 treats deep modules as units of long-term investment. 62 00:03:27,000 --> 00:03:31,000 In practice, this moves review questions from "does it work?" 63 00:03:31,000 --> 00:03:35,000 toward "what must the next reader know in order to change it 64 00:03:35,000 --> 00:03:38,000 safely?" Design is not a separate ceremony; it is embedded in 65 00:03:38,000 --> 00:03:43,000 names, boundaries, exceptions, comments, layers, and performance 66 00:03:43,000 --> 00:03:44,000 choices. 67 00:03:44,000 --> 00:03:48,000 L3 · Insight Cards A Philosophy of Software Design - I2.1 68 00:03:48,000 --> 00:03:52,000 Working behavior is the start of design judgment, not its finish 69 00:03:52,000 --> 00:03:56,000 line A Philosophy of Software Design - I2.2 A deep module is 70 00:03:56,000 --> 00:04:00,000 evaluated by the burden it removes from users A Philosophy of 71 00:04:00,000 --> 00:04:04,000 Software Design - I2.3 Strategic programming is repeated small 72 00:04:04,000 --> 00:04:08,000 investment, not a heroic rewrite L4 · Production Board Outputs 73 00:04:08,000 --> 00:04:12,000 Blog draft: Part 2 as "Working Code Is Not Enough" Code review 74 00:04:12,000 --> 00:04:16,000 question: Where does quickly working code diverge from code that 75 00:04:16,000 --> 00:04:18,000 remains understandable tomorrow? 76 00:04:18,000 --> 00:04:22,000 Insight card: Working behavior is the start of design judgment, 77 00:04:22,000 --> 00:04:26,000 not its finish line L5 · Review Connections: This stands in 78 00:04:26,000 --> 00:04:30,000 tension with YAGNI: avoid speculative generality, but also avoid 79 00:04:30,000 --> 00:04:32,000 tactical blindness to future change. 80 00:04:32,000 --> 00:04:36,000 Open questions: Where does this part's red flag appear most 81 00:04:36,000 --> 00:04:38,000 clearly in my current codebase? 82 00:04:38,000 --> 00:04:42,000 What check would an AI coding agent need in order to apply this 83 00:04:42,000 --> 00:04:44,000 principle reliably? 84 00:04:44,000 --> 00:04:48,000 Final takeaway: A deep module is not one that hides for its own 85 00:04:48,000 --> 00:04:49,000 sake; it lets users know less while doing more.