1 00:00:00,000 --> 00:00:04,000 A Philosophy of Software Design Part 5 - Boundaries and Errors 2 00:00:04,000 --> 00:00:08,000 Are Design Choices A Philosophy of Software Design treats 3 00:00:08,000 --> 00:00:12,000 software design less as architectural theater and more as the 4 00:00:12,000 --> 00:00:14,000 daily work of managing complexity. 5 00:00:14,000 --> 00:00:18,000 This part covers Chapter 9 Better Together Or Better Apart? 6 00:00:18,000 --> 00:00:21,000 and Chapter 10 Define Errors Out Of Existence. 7 00:00:21,000 --> 00:00:24,000 It uses only short key phrases from the source and turns the 8 00:00:24,000 --> 00:00:28,000 reading into summary, interpretation, and application. 9 00:00:28,000 --> 00:00:32,000 The guiding question is: Where should a good design split, and 10 00:00:32,000 --> 00:00:33,000 where should it join? 11 00:00:33,000 --> 00:00:37,000 How to use this note This is part 5 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 9 Better Together Or Better Apart? 14 00:00:43,000 --> 00:00:46,000 and Chapter 10 Define Errors Out Of Existence. 15 00:00:46,000 --> 00:00:50,000 The operating principle remains: book notes are storage; insight 16 00:00:50,000 --> 00:00:51,000 cards are currency. 17 00:00:51,000 --> 00:00:55,000 L0 · Entry Core sentence: Module boundaries and error handling 18 00:00:55,000 --> 00:00:59,000 should both reduce the number of cases users must understand. 19 00:00:59,000 --> 00:01:03,000 Why read this: As AI tools and automation make code faster to 20 00:01:03,000 --> 00:01:06,000 produce, I want sharper standards for code that remains 21 00:01:06,000 --> 00:01:08,000 understandable and changeable. 22 00:01:08,000 --> 00:01:12,000 Initial hypothesis: Splitting code and handling errors often 23 00:01:12,000 --> 00:01:14,000 look like separate topics. 24 00:01:14,000 --> 00:01:18,000 Here they become one question: how many cases does the interface 25 00:01:18,000 --> 00:01:19,000 expose to users? 26 00:01:19,000 --> 00:01:23,000 Author context: John Ousterhout is a computer scientist known 27 00:01:23,000 --> 00:01:27,000 for work in operating systems, distributed systems, Tcl/Tk, and 28 00:01:27,000 --> 00:01:30,000 software design education at Stanford. 29 00:01:30,000 --> 00:01:33,000 Scope: Chapter 9 Better Together Or Better Apart? 30 00:01:33,000 --> 00:01:37,000 and Chapter 10 Define Errors Out Of Existence L1 · Captures 31 00:01:37,000 --> 00:01:41,000 Short phrase · design "better together" Shared information can 32 00:01:41,000 --> 00:01:43,000 make joining simpler than splitting. 33 00:01:43,000 --> 00:01:47,000 Separation rules create complexity when applied without context. 34 00:01:47,000 --> 00:01:51,000 Short phrase · design "define errors out of existence" This 35 00:01:51,000 --> 00:01:54,000 favors removing error states instead of adding more 36 00:01:54,000 --> 00:01:55,000 error-handling code. 37 00:01:55,000 --> 00:01:59,000 Preventing exceptions can be deeper than catching them. 38 00:01:59,000 --> 00:02:03,000 Short phrase · design "special cases" This points to cases that 39 00:02:03,000 --> 00:02:04,000 widen the interface. 40 00:02:04,000 --> 00:02:08,000 The first question is whether a special case can become part of 41 00:02:08,000 --> 00:02:10,000 the general rule. 42 00:02:10,000 --> 00:02:13,000 Copyright boundary This public note does not reproduce long 43 00:02:13,000 --> 00:02:15,000 source passages. 44 00:02:15,000 --> 00:02:18,000 It uses chapter-level concepts and short phrases as anchors, 45 00:02:18,000 --> 00:02:22,000 then provides transformative summary and commentary. 46 00:02:22,000 --> 00:02:25,000 L2 · Map Range Summary Main claim --- ------ --------- 47 00:02:25,000 --> 00:02:29,000 ------------ 1 Joining Keep code together when knowledge is 48 00:02:29,000 --> 00:02:33,000 shared or the interface becomes simpler Separation creates 49 00:02:33,000 --> 00:02:37,000 information movement cost 2 Splitting Separate general-purpose 50 00:02:37,000 --> 00:02:41,000 code from special-purpose code Not all coupling is bad, and not 51 00:02:41,000 --> 00:02:45,000 all separation is good 3 Eliminating duplication Duplication 52 00:02:45,000 --> 00:02:49,000 caused by splitting can signal a wrong boundary Duplicated 53 00:02:49,000 --> 00:02:52,000 knowledge may reveal boundary failure 4 Exception complexity 54 00:02:52,000 --> 00:02:56,000 Exceptions increase paths outside the normal flow Error handling 55 00:02:56,000 --> 00:03:00,000 is part of the interface surface 5 Removing errors Impossible 56 00:03:00,000 --> 00:03:04,000 states reduce handling code Design can replace some validation 57 00:03:04,000 --> 00:03:08,000 work Argument in one paragraph: Module boundaries and error 58 00:03:08,000 --> 00:03:12,000 handling should both reduce the number of cases users must 59 00:03:12,000 --> 00:03:13,000 understand. 60 00:03:13,000 --> 00:03:17,000 Splitting code and handling errors often look like separate 61 00:03:17,000 --> 00:03:18,000 topics. 62 00:03:18,000 --> 00:03:22,000 Here they become one question: how many cases does the interface 63 00:03:22,000 --> 00:03:23,000 expose to users? 64 00:03:23,000 --> 00:03:27,000 In practice, this moves review questions from "does it work?" 65 00:03:27,000 --> 00:03:31,000 toward "what must the next reader know in order to change it 66 00:03:31,000 --> 00:03:35,000 safely?" Design is not a separate ceremony; it is embedded in 67 00:03:35,000 --> 00:03:39,000 names, boundaries, exceptions, comments, layers, and performance 68 00:03:39,000 --> 00:03:41,000 choices. 69 00:03:41,000 --> 00:03:45,000 L3 · Insight Cards A Philosophy of Software Design - I5.1 Module 70 00:03:45,000 --> 00:03:49,000 boundaries should follow the flow of shared knowledge, not the 71 00:03:49,000 --> 00:03:53,000 number of objects A Philosophy of Software Design - I5.2 Error 72 00:03:53,000 --> 00:03:57,000 handling is an interface surface problem before it is a failure 73 00:03:57,000 --> 00:04:00,000 response problem A Philosophy of Software Design - I5.3 74 00:04:00,000 --> 00:04:04,000 Designing away special cases reduces branching in the caller's 75 00:04:04,000 --> 00:04:08,000 mind L4 · Production Board Outputs Blog draft: Part 5 as 76 00:04:08,000 --> 00:04:12,000 "Boundaries and Errors Are Design Choices" Code review question: 77 00:04:12,000 --> 00:04:16,000 Where should a good design split, and where should it join? 78 00:04:16,000 --> 00:04:20,000 Insight card: Module boundaries should follow the flow of shared 79 00:04:20,000 --> 00:04:24,000 knowledge, not the number of objects L5 · Review Connections: 80 00:04:24,000 --> 00:04:28,000 This connects to domain modeling: making impossible states 81 00:04:28,000 --> 00:04:32,000 unrepresentable moves error handling from response to design. 82 00:04:32,000 --> 00:04:35,000 Open questions: Where does this part's red flag appear most 83 00:04:35,000 --> 00:04:37,000 clearly in my current codebase? 84 00:04:37,000 --> 00:04:41,000 What check would an AI coding agent need in order to apply this 85 00:04:41,000 --> 00:04:43,000 principle reliably? 86 00:04:43,000 --> 00:04:47,000 Final takeaway: A good boundary is not a decorative line through 87 00:04:47,000 --> 00:04:48,000 code; it is a device for reducing the user's cases.