Old Is the New New • Kevlin Henney • GOTO 2018

复古即前沿 • Kevlin Henney • GOTO 2018 在这场主题演讲中，Kevlin Henney审视了软件行业长期的集体健忘症，以及将古老的计算思想重新包装为全新创新的习惯。通过追溯现代架构范式、测试驱动开发、垃圾回收和函数式编程至20世纪30年代至70年代的里程碑——包括Algol 68、1968年北约会议和Unix管道——Henney展示了现代团队如何反复解决几十年前就已被攻克的问题。他批评了行业过度工程化、构建不必要分布式系统以及过度进行多线程同步的倾向，转而提倡小型、简单的实现与清晰边界的价值。最终，他鼓励开发者学习计算机科学历史，以便停止重造过去的轮子，并将精力集中在真正独特的挑战上。 软件开发饱受历史健忘症之苦，经常将20世纪60和70年代的基础概念——例如lambda表达式、垃圾回收和迭代设计——重新包装为全新的现代范式。 (0:15) 1968年的北约软件工程会议指出，前期预先完成软件规格说明本质上存在问题，设计必须是迭代式的，这推翻了瀑布模型在早期是普遍标准的普遍看法。 (13:51) 物理计算限制决定了本地内存操作性能优于网络调用，正如命令行Unix工具处理2 GB数据集的速度比分布式Hadoop集群快200倍所证明的那样。 (18:59) Jack Reeves和1968年北约会议表明，编码是一种迭代式的设计活动而非制造活动，因为软件的复制和编译几乎不产生物理成本。 (36:47)

Software development operates under an illusion of constant change, suffering from a weak historical memory that leads teams to repeatedly reinvent established practices. Speaker Kevlin Henney argues that most supposed innovations in architecture, testing, and language design are merely repackaged principles dating back to the 1960s and 1970s. The Illusion of Novelty in Modern Paradigms (0:15) The tech industry routinely mistakes rebranding for genuine technical progress. Modern language communities celebrate capabilities like lambdas—championed by C++ in 2011 and Java in 2014—even though closures and anonymous procedures were present in Algol 68 and Lisp decades earlier, with theoretical roots extending to Alonzo Church’s lambda calculus in the 1930s. Similarly, functional data manipulation has long been mainstream through tools like spreadsheets, which Simon Peyton Jones noted make Excel the most widely used functional language. Iterative Design Versus Upfront Specification (13:51) Rigid planning methodologies were rejected by early software pioneers well before modern agile frameworks appeared. At the 1968 NATO Software Engineering Conference, Andy Kinslow noted that design is fundamentally iterative, while Douglas Ross cautioned that specifying everything upfront is the root of software failures. Winston Royce’s 1970 paper is often misconstrued as an endorsement of waterfall, even though the broader industry had already recognized the reality of iterative development. Simplicity, Scope, and Physical Constraints (11:05) Modern architectures frequently overcomplicate systems by pursuing bloated requirements and unnecessary network distribution. Richard P. Gabriel's 1990 concept of "Worse Is Better" demonstrated that minimal, disposable implementations offer greater leverage than sprawling systems, exemplified by Ward Cunningham launching the original wiki using only 150 lines of Perl. Small codebases keep systems within human cognitive limits, echoing Dennis Ritchie and Ken Thompson's 1970 observation that size constraints foster design elegance. Testing Traditions and Architectural Boundaries (31:38) Core testing and architecture methodologies likewise originate in classic engineering texts. The test-first discipline behind Test-Driven Development was practiced in the 1970s by Alfred Aho, Peter Weinberger, and Brian Kernighan on AWK, where writing tests was mandatory before adding new language features. Similarly, Behavior-Driven Development’s Given-When-Then pattern aligns with Tony Hoare's 1969 axiomatic logic. For modularity, David Parnas demonstrated in 1972 that architectural boundaries should hide volatility and difficult decisions, rather than simply mimicking external nouns. Concurrency, State Isolation, and Coordination (41:45) Modern concurrency issues frequently stem from a fixation on shared-memory multithreading and synchronization, which Henney argues defeats concurrency by forcing execution to wait. Decades of work in Erlang, Occam, and Tony Hoare’s Communicating Sequential Processes proved that isolated state paired with message passing provides a more resilient alternative. On a systems level, Nicholas Carriero and David Gelernter divided programming models into computation and coordination, a concept mirrored in Doug McIlroy's 1964 design for Unix pipes to stream data seamlessly between simple utilities. Recognizing that modern architectures draw from a small, stable set of decades-old principles allows engineers to avoid superficial hype cycles, focus on genuine differences in emerging tools, and build smaller, more comprehensible systems.

Kevlin Henney 在 GOTO 2018 演讲中指出，软件开发行业表面上充斥着快速更迭与工具炒作，实则普遍缺乏历史认知；当代备受推崇的诸多“创新”设计理念与工程实践，本质上大多是对数十年前计算先驱成熟成果的重复发现与包装。 技术概念的历史遗忘与语言源流 (0:15) 软件行业长期处在一种对工程发展史集体失忆的状态中。现代开发者常将自动垃圾收集（Garbage Collection）或匿名函数视为近期的突破性演进，但这些机制早在 1960 年运行的 Lisp 实现、1967 年的 Simula 以及 1968 年的 Algol 68 中便已完备落地。Algol 68 不仅缩写了 int、char、struct 等沿用至今的类型系统，更率先引入了表达式优先语法和捕获作用域变量的闭包机制。类似地，主流面向对象编程在 2010 年代后大肆宣传 Lambda 特性，而该特性的数理基础早在 1930 年代便由 Alonzo Church 的 Lambda 演算确立，并由 Simon Peyton Jones 指出早在商业电子表格中就已作为函数式模型广泛铺开。 敏捷迭代与规约神话的早期反思 (13:51) 敏捷开发所倡导的迭代演进与反预先详尽设计常被当成千禧年后的新潮理念，但 1968 年在加米施举行的首届北约软件工程会议上，Andy Kinslow 就已明确记录了“设计过程本就是迭代过程”的共识。会议代表 Douglas Ross 更是尖锐批评全量前期规约才是系统性问题的根源；将瀑布模型归咎于 Winston Royce 1970 年论文的行业流行看法也是一种历史误读。事实上，Margaret Hamilton 早在 1960 年代为阿波罗登月计划编写机载系统时便创造了“软件工程”这一术语，以此强调容错与系统级工程地位。 Edward Berard 在 1991 年便断言只有在“水与规范同样冻结”时才能脱离编程直接从规范实现软件。所谓完全无歧义、能够直接生成可执行程序的详尽规范，其本质其实就是源代码本身。Ward Cunningham 在 1992 年提出“技术债务”隐喻时，初衷在于说明像房贷一样借入短期设计妥协以快速验证想法是合理交易，前提是必须及时通过重构偿还本金，否则系统必然如 Alan Perlis 所言，在无节制的装饰与补丁中从洛可可风格沦为建筑废墟。 极简原则与物理距离的工程代价 (11:05) Richard P. Gabriel 在 1990 年提出的“更差即更好”（Worse Is Better）哲学常被误读为鼓励粗制滥造，但其实质是倡导极致的极简设计与收敛的作用域。Ward Cunningham 于 c2.com 上用仅 150 行 Perl 脚本写就最初的 Wiki，其核心优势在于极小体积所赋予的可理解性与可重写性，这与企业级架构动辄耗费数月评审出臃肿庞然大物的做法形成鲜明反差。Dennis Ritchie 与 Ken Thompson 在 1970 年指出，系统物理边界带来的尺寸约束能倒逼出设计的经济与优雅；John Lions 编写的经典 Unix 内核注释全篇也仅有 9,500 行代码，反衬出当代企业级系统中动辄出现引力黑洞般巨大类的荒谬。 而在系统性能层面，工程界在上世纪便总结出“没有代码比无代码更快”及“最快 I/O 即无 I/O”的公理。过度迷信分布式大数据的倾向往往无视了硬件物理定律：光速传播每纳秒仅约一英尺，大致对应 1 GHz 处理器的一个时钟周期；本地单机总线延迟在纳秒级别，而跨网络传输则有着不可逾越的物理延迟惩罚。Adam Drake 在 2014 年证实，对于能在单机内存完全容纳的 2GB 数据集，单机 Unix 命令行管道的处理性能可以比庞大的分布式 Hadoop 集群快出 200 倍以上。因此在缺乏绝对业务刚性约束时，盲目将系统分散到网络端只会凭空制造延迟与维护开销。 测试理论与模块架构演变真伪 (31:38) 软件测试与模块化理念的理论脉络同样远早于当代的商业包装。Alfred Aho 等人在 1970 年代设计 AWK 语言时便制定了强制性的测试先行策略，任何新增特性都必须先提交回归测试；行为驱动开发（BDD）中通用的 Given-When-Then 范式，其数学本质可直接追溯至 Tony Hoare 在 1969 年发表的形式化公理逻辑（Hoare 三元组）。在架构分解方面，David Parnas 1972 年关于信息隐藏的开创性论文明确要求将模块边界建立在最易变、最困难的设计决策周围，用稳定接口隔离不确定性，而非围绕直观的名词进行静态数据建模；Edward Yourdon 与 Larry Constantine 也在 1970 年代将高内聚与低耦合确立为对抗认知负荷的核心手段。 主流面向对象阵营对继承层级的痴迷，严重偏离了 Alan Kay 最初对面向对象的定义——即通过去中心化的自治实体进行消息传递、局部状态隐藏与极限后期绑定。在并发领域，Java 早期在集合类中盲目引入内部同步锁导致了严重的并发失效，因为同步的本质就是消灭并发以换取安全性。基于独立保护状态与消息传递的并发模型，早在 1970 年代便通过 Carl Hewitt 的 Actor 模型以及 Tony Hoare 的通信顺序进程（CSP）得以确立，并在 Erlang 与 Occam 等语言中受尽检验。而在宏观架构层面，Doug McIlroy 在 1964 年构想并由 Ken Thompson 在 1970 年实装的 Unix 管道，早为计算模型与协调模型的解耦融合提供了典范范式。 软件开发者的核心生产力瓶颈始终受制于人类不变的认知带宽，而系统的底层原则历经数十年演进并无本质颠覆。Henney 借由顾问仅凭全局替换“对象”、“组件”、“服务”到“微服务”关键词便能跨越多次技术泡沫兜售同一套方案的真实笑谈警示行业：与其在不断变换的技术营销词汇中盲目追赶与重复造轮子，不如深入理解计算机科学的真实历史，唯有明晰思想的既有脉络，工程师方能准确甄别真正的突破性创新。

## Background 本视频由 GOTO Conferences 于 2018 年 5 月 15 日在 YouTube 平台发布，记录了资深技术专家与作家 Kevlin Henney 在 GOTO Chicago 2018 大会上的演讲。页面简介指出，演讲探讨了在每周都在经历技术更迭、框架轮替的表象之下，软件行业数十年来变化极少的核心理念潜流，并推荐了演讲者编写的多本经典架构与编程著作。 ## TL;DR Kevlin Henney 深刻剖析了软件工程领域严重的“文化历史健忘症”，揭示当下被狂热追逐的微服务、响应式、Lambda 表达式及敏捷迭代等所谓“颠覆性创新”，实际上早在 1960 至 1970 年代就已经被完整提出并付诸实践。他结合 Algol 68、Unix 哲学、NATO 软件工程会议报告以及测试驱动思想的演进，指出编程的本质始终是认知负荷极高的人类“设计活动”而非工业制造。通过重新审视“差即是好”（Worse is Better）哲学与光速等物理限制，演讲强调唯有理解这些沉淀已久的核心思想，开发者才能看穿概念炒作，避免在周期性的技术轮回中盲目重复发明轮子。 ## Atmosphere & style 整场演讲洋溢着英式冷幽默、辛辣讽刺与博学考据交织的独特氛围。Henney 以莎士比亚戏谑内存管理、将单例模式比作单一麦芽威士忌开场，台下笑声不断，但随之而来的历史文献引述却严谨得令人肃然起敬。观众在聆听时不仅能感受到打破技术迷信的畅快淋漓，更会陷入对行业盲目造词与重复造轮的深刻反思，情绪随着一段段被遗忘的历史真相被揭开而逐渐走向深邃与释然。 ## Bulletin - [00:00](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=0s) 软件行业普遍存在“文化历史健忘症”，大量被视作当下最前沿的技术突破（如垃圾回收、Lambda 闭包、迭代开发、微服务等），早在 1960 至 1970 年代就已被完整提出并实现。 - [08:09](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=489s) Dick Gabriel 提出的“以劣为优”（Worse is Better）常被误读为推崇低质代码，其本意是倡导功能范围精简、但代码坚如磐石、快速小巧的实现，以极简性换取极低替换成本与长期演进空间。 - [36:47](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=2207s) 编程全过程实质上是智力密集型的“工程设计”，软件中唯一对应传统制造阶段的是几乎零成本的编译与文件拷贝，误用制造业流水线方式管理软件开发是诸多行业灾难的根源。 - [17:07](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=1027s) 架构范式每隔约 11 年就以新词汇进行一次轮回包装，盲目推崇分布式与微服务常因忽视冷酷的光速物理法则而遭遇性能惩罚，单机内存处理往往比过度设计的集群快上数百倍。 ## Key takeaways - [00:00](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=0s) 技术框架与工具的快速迭代掩盖了底层数十年未变的稳定潜流，理解历史概念能够让工程师看穿表象并专注于核心本质。 - [02:12](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=132s) 垃圾回收和现代语言语法特性并非现代专属，1960 年代初的 Lisp、Simula 67 以及 Algol 68 早已成熟支持垃圾回收、闭包和表达式导向语法。 - [05:56](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=356s) 设计模式本质上是对原创性的“进取性无视”，软件工程的大部分工作应当复用经过验证的成熟模式，而非为了创新而重新发明轮子。 - [11:05](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=665s) “差即是好”主张实现简单性高于完整性，如 Ward Cunningham 最初仅用 150 行 Perl 脚本就构建出具备极高演进弹性的原版 Wiki。 - [13:51](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=831s) 迭代开发思想早在 1968 年 NATO 软件工程会议上便被明确倡导，与会先驱早已严厉批判了“先全面规划规格再动手编码”的危害。 - [17:07](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=1027s) 速度是极其重要的可用性属性，受制于光速与物理延迟，在单机内存容纳范围内利用本地工具处理数据，其效率可达盲目上云或大数据集群的数百倍。 - [21:12](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=1272s) 人类有限的认知带宽决定了系统可维护性上限，Unix 第 6 版内核仅用 9500 行代码就构建了完备的操作系统，而现代业务系统充斥着超出人脑理解边界的巨型类。 - [23:57](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=1437s) 缺乏约束会导致系统演变成无人知晓其原理、仅靠巧合运转的“巨石遗迹”（Monolith），严苛的尺寸与边界约束反而催生优雅与高效的设计。 - [27:03](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=1623s) 微服务、组件软件与 Unix 哲学本质相通，核心均在于构建高内聚、小规模、可独立测试并部署的单元，概念每隔约 11 年就会改头换面重现一次。 - [30:03](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=1803s) Alan Perlis 在 1968 年就提倡将测试与设计交织在一起；1970 年代 AWK 的开发完全遵循了严格的测试先行，而“Given-When-Then”结构直接脱胎于 1969 年的 Hoare 逻辑。 - [34:02](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=2042s) 技术债务最初指代类似按揭贷款的权衡策略，用于短期加速交付，但若不及时重构还清，未完全写对的代码所产生的持续利息会拖垮系统。 - [36:47](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=2207s) 编程是一项纯粹的设计活动而非生产制造，试图绕过代码直接依据规范自动生成可用软件的迷思，历史上每隔十年就会以某种形式卷土重来。 - [38:27](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=2307s) David Parnas 早在 1972 年就提出模块化应围绕“隐藏易变的设计决策”展开；面向对象在 Alan Kay 的最初设想中核心是消息传递与局部状态保护，而非静态类继承。 - [41:45](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=2505s) 同步机制的本质是消除并发，滥用共享内存锁机制会导致系统变慢并充斥 Bug，采用基于消息传递的独立进程或 Actor 模型能更好地实现并行。 - [46:04](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=2764s) 系统架构应清晰解耦“计算模型”与“协调模型”，如 Unix 管道所代表的串联数据流思想，展现了将独立计算单元灵活编织协同的优雅范式。 ## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=0s) 恒常变革之下的静止水流与历史健忘症 在演讲开场时，Kevlin Henney 幽默地向台下保证，为了换换口味，这次演讲绝对不会出现任何系统崩溃或报错截图（fail screens）。他切入本次演讲的核心主题：“老即是新”（Old Is the New New）。任何在软件行业摸爬滚打超过数年的人，只要退后一步纵观技术潮流，就会察觉到一种奇特的二元对立：在表面瞬息万变的框架与工具之下，存在着一股极其平缓、稳定且数十年几乎未曾改变的潜流。面对当今爆炸式的技术增长，没有人能跟上每一个新技术，但理解底层概念的人却能看穿表象——每当面对新玩意时，只需问一句“这东西像过去的什么？它的不同之处在哪里？我真正需要关注的核心是什么？”很多时候，那些让年轻开发者惊呼从未见过的前沿理念，实际上早在 1972 年或 1974 年就已经被完整提出并实现了。 软件行业存在着极为严重的“文化历史健忘症”。Kevlin Henney 引用了法国作家安德烈·纪德（André Gide）的名言来揭示这种行业现状：“一切都已被说过，但既然无人倾听，我们就必须一次又一次地重新开始。”行业并不只是在不断重复发明轮子、寄希望于某天终于能把它做圆，而是因为缺乏对历史的纵深感知，永远处于一种自我感动的“惊奇与重新发现”状态之中。 - 行业常态是误将半个世纪前的旧思考包装为当下最前沿的技术突破。 - 对历史的无知导致工程师反复踏入前人早已踩平或规避过的技术陷阱。 > “Everything has been said before, but since nobody listens, we must also and we must always start again because there's something else in software that we are particularly bad at: we have a very weak sense of history.” —— Kevlin Henney --- ### [02:12](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=132s) 莎士比亚的内存管理与 1960 年代的高级语言真相 为了戏谑地证明“历史比想象中更早”，Henney 开玩笑称莎士比亚其实是人类最早的程序员之一。由于伊丽莎白时代的硬件条件严重不足，莎士比亚只能编写脚本（剧本），并通过“Actor 模型”（即雇佣剧团演员）来执行代码；而他的剧作表面上是戏剧，实则是对现代计算问题的伪装评论。例如《哈姆雷特》通篇都在探讨内存管理：奥菲莉娅的台词“谨将此心锁于记忆，钥匙交由您保管”分明是在描述痛苦的“手动内存管理”（Manual Memory Management）；而哈姆雷特高呼“从我记忆的记录表上，拭去一切轻浮平庸的记载”，则分明是在欢呼“垃圾回收”（Garbage Collection），甚至顺带预言了数据库记录与数据迁移。 玩笑过后，Henney 指出当下人们谈论垃圾回收时，总以为这是现代虚拟机的专属创新。实际上，Lisp 常常被错误地归为 1950 年代的产物，但 Henney 强调他只认可“能够实际运行的系统”，纸面草案不能算数。Lisp 的第一个实际运行版本诞生于 1960 年，彼时就已完整搭载了垃圾回收器。很多人以为垃圾回收当时仅限于函数式编程这种小众领域，但事实完全相反。Algol 68（1968 年发布）作为当时被视为庞大、野心过大以至于难以实现的面向过程语言，同样支持垃圾回收。如今 Algol 68 的规格甚至比现代大多数语言都要小，并且它是有史以来影响力最大、却极少有人听说或使用过的语言。Algol 68 不仅确立了 `int`（缩短自 60 年代常用的 `integer`）、`char`、`long`、`short`、`struct` 和 `union` 等经典类型关键字，而且是完全以“表达式为主”（expression-oriented）的——每条语句都产生值，无需为 `if` 语句和表达式设计两套语法（同时带来了配对的 `fi` 语法），甚至原生支持能够捕获闭包变量的匿名过程（即 Lambda 表达式）。此外，面向对象编程的先驱 Simula 67（1967 年）也同样具备垃圾回收功能。早在 1960 年代末，这些看似现代的机制就已经是成熟的技术基石。 ```mermaid flowchart TD accTitle: 1960年代编程语言的现代特性血统演进图 accDescr: 展示Lisp、Simula 67与Algol 68在1960年代已经实现的现代语言特性。 subgraph 1960s["1960 年代成熟技术"] Lisp["1960: Lisp (首次实机运行)<br/>- 垃圾回收 (Garbage Collection)<br/>- 函数式编程"] Simula["1967: Simula 67<br/>- 面向对象萌芽<br/>- 内置垃圾回收"] Algol["1968: Algol 68<br/>- 表达式导向 (Expression-oriented)<br/>- 闭包与匿名过程 (Lambda)<br/>- 类型关键字 (int, char, struct)<br/>- 垃圾回收"] end subgraph Modern["现代语言频繁‘重新发明’的特性"] GC["自动内存管理 / 垃圾回收"] Lambdas["Lambda 表达式 / 闭包捕获"] ExprSyntax["表达式语法 (一切皆有返回值)"] end Lisp --> GC Simula --> GC Algol --> GC Algol --> Lambdas Algol --> ExprSyntax ``` - Lisp 纸面设计始于 1950 年代末，首个可运行版本诞生于 1960 年并自带垃圾回收。 - Algol 68 开创了大量当代 C 族语言继承的简写类型名（如 `int` 替代 `integer`）。 - Algol 68 在过程式编程中实现了闭包捕获与 Lambda 表达式，证明现代语言争相引入的特性在半个世纪前就已落地。 > “Algol 68 is the most influential language that few people have ever heard of or used.” —— Kevlin Henney --- ### [05:56](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=356s) 设计模式与单一麦芽威士忌：对原创性的进取性无视 谈到“旧概念”的价值，Henney 提及了自己参与撰写的设计模式书籍。他戏谑道，很多人一提起设计模式，脑子里就只有“单例模式”（Singleton）。但在他看来，世界上只有两种好的单例：第一种是用来招揽顾问咨询业务的单例——“您好，您的单例出问题了吗？我很乐意为您提供付费咨询”；第二种唯一对代码有益的单例，其实是一杯“单一麦芽威士忌”（Single Malt）。当琥珀色的酒液滑入喉咙、灼热感在口中荡漾开来时，你停下敲代码的手沉思片刻：“或许……我不应该在系统的正中央塞进那个庞大无比的全局变量。”这一瞬间的天人合一，仅靠“无为”就让代码质量得到了升华。经验表明，一个系统里的单例要么是 0 个，要么就充斥着两个以上，极少真的刚好只有一个。 抛开单例的调侃，模式的深层意义远非死记硬背书里的结构。早年间业界狂热追求制定各种“宣言”时，Henney 曾在一家公司的架构工坊中在白板上写下了“模式宣言”：**“我们正在通过观察前人的做法，来发现开发软件的更佳途径。”** Henney 赞同 Brian Foote 的论断——设计模式本质上是对“原创性的一种进取性无视”（aggressive disregard of originality）。整个软件工程构建的大部分内容本就不该追求原创，绝大多数问题在历史上早已被前人解决，而业界目前极其匮乏的是将成熟解法顺畅沟通传承的能力。真正的核心精力，应该保留给业务中极少数真正具备原创性的那一小部分。 - 单例模式在现实项目中的反常现象：系统中若存在单例，往往不仅是一个，而是出现两个或更多。 - 软件模式的核心精神是拒绝为了创新而创新，专注于提取和复用已经验证过的解决方案。 > “As Brian Foote said, patterns are aggressive disregard of originality. It is the idea that most of what we build is unoriginal and should be.” —— Kevlin Henney --- ### [08:09](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=489s) 误读的“以劣为优”哲学与极限极简主义 由模式社群的关键人物 Dick Gabriel 在 1990 年提出的“以劣为优”（Worse is Better）哲学，遭遇了业界长达数十年的严重误读。Gabriel 随后在 1990 年代中期出版的随笔集中回顾了这一构想。Henney 吐槽指出，软件工程最难的事情之一就是命名，而“Worse is Better”简直是 Gabriel 能取出的最糟糕、最容易引起误解的名字。这个名字本身就带有冷幽默与讽刺意味：许多人一听到这个词，就望文生义地以为是鼓吹“随手写点垃圾代码丢出去就行，反正能用就够了”（这实际上属于另一个名为“Good Enough Software”的流派）。 Gabriel 提出该理论时的真正含义在于：如果软件在开发时采用“最小发明”（minimal invention），反而更容易取得商业与工程上的成功。换言之，尽量复用成熟已知的事物，只在未知的边缘做增量。Dick Gabriel 口中被冠以“劣”（Worse）的软件，在技术特质上极其颠覆常识： 1. **坚如磐石（Rock-solid）**：绝对无 Bug、具备防弹级的稳定性； 2. **极速运行（Fast）**：高效且响应敏捷； 3. **体积小巧（Small）**：代码库轻量、资源占用极低。 大众眼里的“差劲/劣等”通常是臃肿、缓慢、漏洞百出，而 Gabriel 所谓的“劣”，其唯一的评判标准落在**需求范围**上：相比于领域专家所设想的“功能齐全的完备系统”，它是一个功能精简（under-featured）、范围极度克制、仅覆盖最小核心需求的产品。这一理念早于现代敏捷开发（Agile Development）与快速应用开发（RAD），其核心支柱第一条便是“简单性”（Simplicity）——尽管业界因为健忘而不得不一遍又一遍地重新强调它。 - “Worse is Better”中的“Worse”单指**特性的不完备与最小化范围**，而非代码质量或工程实现的低劣。 - 成功的软件往往具备极其克制的初始需求集，同时保持极高的质量、速度与紧凑性。 > “It is far better to have an under-featured product that is rock-solid, fast and small. Now when most people think worse, they do not think of these three qualities.” —— Kevlin Henney ### [11:05](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=665s) “差即是好”中的极简实现与 Ward Cunningham 的 Wiki Kevlin Henney 继续深入探讨“差即是好”（Worse is Better）哲学的核心要素。在该哲学中，实现的简单性占据绝对首位：接口应当简单，但“只要够用就行”，它不必惊艳，只要不愚蠢、不糟糕即可。这种做法带来了一个极其重要的工程特性——如果实现足够简单，你就可以轻松丢弃它、替换它、修改它，并且完全理解它。至于完整性（Completeness），设计只需覆盖必要的情景，为了换取其他质量属性，完整性完全可以被牺牲。 为了说明这一点，Henney 列举了 Ward Cunningham 发明最初 Wiki 的经典案例。原版 Wiki 的 Perl 脚本仅仅只有 150 行代码。虽然 Henney 开玩笑说，Perl 是一种对人类来说晦涩如象形文字的糟糕语言，但这区区 150 行代码却撑起了一个可编辑网页的原型。相较于企业团队花费 18 个月、产出庞大到压垮任何 Java 项目的复杂系统，Cunningham 仅凭几条约定和极轻量的代码就让系统运转了起来。c2.com 上的原版 Wiki 虽不完美也不完整，却孕育出了后来的 MediaWiki 乃至维基百科（Wikipedia）的庞大基础设施。代码足够小，使得重写和定制变得轻而易举，同时也为后续扩展留下了巨大的空间。此外，正确性要求设计在所有可观察的方面都必须正确；而一致性则通过“始终优先选择最小范围”来保障，因为范围越小，保持一致就越容易。这本质上就是一种持续迭代、不断增量调整并敢于舍弃的演进式开发方式。 - **实现简单的核心价值**：低成本丢弃、轻松替换、易于修改与透彻理解。 - **原版 Wiki 的精简度**：Ward Cunningham 最初仅用约 150 行 Perl 脚本就实现了可编辑网页系统的核心功能。 - **增量策略与范围控制**：优先实现最小范围，在后续迭代中根据需要增补或废弃。 ### [13:51](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=831s) 1968 年 NATO 会议与软件工程历史的误读 Henney 指出，许多人以为“设计过程是迭代的”这一观点是 1990 年前后才出现的新思想，但实际上早在 1968 年的 NATO 软件工程会议（NATO Software Engineering Conference）报告中，Andy Kinslow 就已经明确写下了“设计过程是一个迭代过程”。正值该会议召开 50 周年之际，业界却依然把“迭代开发”当作某种全新的启示，令人啼笑皆非。 ```mermaid flowchart TD accTitle: 软件工程历史溯源与演进 accDescr: 展示从 Margaret Hamilton 提出软件工程概念到 NATO 会议及母体演示的关键里程碑 subgraph S1["概念奠基与早期工程"] A["Margaret Hamilton (1960年代中期)<br/>阿波罗计划中提出'软件工程'与容错理念"] end subgraph S2["1968 NATO 加尔米施会议"] B["Andy Kinslow: 强调设计过程为迭代式"] C["Douglas Ross: 批判'先全面规格化再动手编码'"] end subgraph S3["1968 秋季联合计算机会议 (FJCC)"] D["Douglas Engelbart 的'母体演示'<br/>展示动态链接、鼠标、视讯会议"] E["Alan Kay 等人受其启发<br/>孕育 Smalltalk 与面向对象体系"] end A --> B B --> C C --> D D --> E ``` 会议不仅确立了诸多前瞻理念，历史本身也常被后人误读。许多人将“软件工程”（Software Engineering）这一词汇的发明归功于 1968 年在加尔米施（Garmisch）召开的这场会议，但实际提出者是阿波罗计划（Apollo）的主导程序员 Margaret Hamilton。她在 1960 年代中期提出了该术语，旨在将软件工程与硬件工程并列，视作整体系统工程的一部分，并开创性地设计了保障登月任务成功的“容错”（fault tolerance）机制。同样地，很多人误以为当时的会议推崇的是“计划驱动开发”，但事实恰恰相反，与会专家早已洞悉前期过度规划的危害。 > “在软件领域，最致命的事情莫过于几乎人人都遵循的那个观念：你先详尽规定要做什么，然后再去做；这就是我们绝大多数麻烦的根源。” —— Douglas Ross，1968 年 NATO 软件工程会议 Henney 强调，根本不需要等到 Winston Royce 1970 年那篇常被误认为是瀑布模型发源地的论文，早在 1968 年，先驱们就已经明确意识到这一陷阱。同年，在 1968 年秋季联合计算机会议（Fall Joint Computer Conference）上，Douglas Engelbart 带来了被誉为“所有演示之母”（The Mother of All Demos）的传奇展示，演示了鼠标、视讯会议以及运行时的动态链接（Dynamic Linking）。台下的观众包括了日后开发出 Smalltalk 的 Alan Kay。 ### [17:07](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=1027s) 极致性能与光速法则：命令行工具如何击败 Hadoop 集群 回到“差即是好”对实现特性的要求——实现必须高效（fast）。Henney 指出，速度往往是最容易被忽视的系统质量属性，因为人们常常曲解了性能优化的建议。事实上，提升系统可用性（Usability）最立竿见影的方法就是让它变快：如果一个操作快到用户根本察觉不到延迟，那么界面按钮放在哪里、等待光标（wait cursor）采用什么颜色或图标，都彻底不再需要争论。性能必须在架构设计的一开始就被持续关注，在没有绝对终点的增量开发中，性能更不能留到最后才处理。 Henney 引用了业界的两条经典格言：“没有什么代码比不写代码更快”（除非未来有人在处理器里造出了快子超光速流水线），以及 1980 年代的经验法则“最快的 I/O 就是没有 I/O”。他分享了一个真实的咨询案例：某个团队花了两年时间对系统进行性能优化，整体吞吐量仅提升了 10%；而 Henney 带领团队介入后，通过识别并彻底消除不必要的 I/O 操作（将原本反复写入外部存储的数据直接保留在内存中），直接让系统性能提升了整整三倍。 为了抨击盲目追逐分布式架构的时弊，Henney 特别推荐了 Adam Drake 在 2014 年撰写的一篇博文《命令行工具可以比你的 Hadoop 集群快 200 倍以上》（*Command-line tools can be over 200 times faster than your Hadoop cluster*）。许多人热衷于将微不足道的数据丢给复杂庞大的大数据集群。在 Drake 的案例中，处理的问题不过是一份 2GB 的数据。在现代笔记本电脑上，2GB 完全可以全部塞进内存处理，甚至还有充裕的剩余空间用来浏览猫咪图片。 | 架构策略 | 典型做法 | 潜在陷阱 / 物理限制 | 适用建议 | |:--- |:--- |:--- |:--- | | **单机 / 内存处理** | 利用 UNIX 命令行或内存管道直接计算 | 受限于单机 RAM 上限（但现代单机容量极大） | 数据量在内存容纳范围内时绝对优先采用 | | **分布式处理** | 盲目推向网络、微服务或 Hadoop 集群 | 受光速与物理延迟限制；网络 I/O 开销巨大 | 仅在单机物理极限无法满足或有极其明确的解耦需求时才考虑 | Henney 郑重告诫：只要有人给你一个“不把数据推向网络”的选项，请毫不犹豫地接受它。将不需要网络通信的操作推向网络，是软件开发中最愚蠢的想法之一。限制这一操作的根本原因不是软件配置，而是冷酷的物理法则——**光速（speed of light）**。光速无法写在配置文件里被随意调大。屏幕宽度约相当于 3 光纳秒的距离；一台笔记本电脑的物理跨度大约是 1 光纳秒，对应约 1GHz 的时钟周期。当把数据传输到地球的另一端时，物理延迟将变得极为惊人。除非有不可抗拒的业务或规模瓶颈，否则永远应当优先把计算和数据保留在本地。而在谈到系统的体积时，Henney 引用了 Edsger W. Dijkstra 的观点：衡量代码质量的标准绝不应当是“产出了多少行代码”，而应当关注系统是否足够精炼与精巧。 ### [21:12](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=1272s) 认知边界与莱昂氏 Unix 源码注记 Kevlin Henney 回顾指出，自己直到 1990 年代都在向人们提出控制规模的建议，后来才发现早在 1970 年代就有人提出过完全相同的观点。软件开发与代码理解的核心瓶颈从未改变，那便是人类自身的认知极限：“你能否把它装进自己的认知边界里？我能否理解它，从而有效地处理它？”一旦开发者无法彻底理解系统，掌控力便会断崖式下跌。计算机性能发生了翻天覆地的变化，但由人类编写和维护软件这一基本事实未变，人脑的处理带宽始终有限。 ```mermaid flowchart LR accTitle: 认知带宽对软件可维护性的影响 accDescr: 当系统规模超出人脑认知边界时理解度骤降导致维护困难 A["系统规模与复杂度"] --> B{"是否在认知边界内?"} B -->|"是"| C["充分理解代码"] --> D["高效开发与安全维护"] B -->|"否"| E["认知超载"] --> F["系统掌控力断崖式下跌"] ``` 为了具象化“小而精”的概念，Henney 提到了 John Lions（新南威尔士大学）在 1970 年代末至 1980 年左右整理的《莱昂氏 Unix 源代码分析》（Lions' Commentary on UNIX 6th Edition）。当时由于反垄断限制，Bell Labs 和 AT&T 无法对 Unix 进行商业推广，Lions 便将其作为操作系统课程讲义，学生们通过地下出版物（samizdat）的方式在复印机前逐页复印流传。Henney 风趣地向年轻听众解释：“复印机就像是一种社交化的扫描仪”，大家在大学图书馆里一边复印一边闲聊。 整整一套完整的操作系统内核代码，仅仅只有 9500 行。Henney 对比道，如今许多业务系统中随处可见超过 9500 行的单一类文件，而这些类所做的事情不过是“从这里读取数据、转换格式、做些运算，再存到那里去”，却庞大臃肿得如同拥有自身引力场一般。 - 软件理解的核心约束是人类的认知带宽，代码一旦超出该边界就无法被有效维护。 - John Lions 整理的 Unix 第 6 版内核仅包含约 9500 行代码，却构成了一个功能完备的操作系统。 - 现代企业系统充斥着体量比 Unix 内核还大、却仅做简单数据存取的“巨型类”。 --- ### [23:57](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=1437s) 严苛约束催生优雅设计与“巨石遗迹”隐喻 谈及创造力，Henney 指出完全没有限制对于创作者而言是一场灾难。如果你去问一个艺术家想要画什么、多大画幅、用什么媒介，得到的回答全都是“随便、不知道”，艺术家只会陷入彻底的沮丧；相反，若给出具体的约束——画一幅风景、规定尺寸大小、以蓝色为主调——创作者反而能激发出惊人的创造力。软件设计同样遵循这一规律。Dennis Ritchie 与 Ken Thompson 早在 1970 年的一篇论文中就强调： > “鉴于对合理效率与表达能力这两个存在部分冲突的需求，尺寸约束不仅促成了精炼节约，更带来了一种设计的优雅。”（“Given the partially antagonistic desires for reasonable efficiency and expressive power, the size constraint has encouraged not only economy but a certain elegance of design.” —— Dennis Ritchie & Ken Thompson） 若在设计系统时宣称“没有任何约束与边界”，系统的质量必然走向崩溃。为了生动展示无约束演进的后果，Henney 晒出了一张他在情人节带家人去英国巨石阵（Stonehenge）拍的照片。面对这堆巨大的远古石阵，他的孩子们疑惑地问道：“我们为什么来这儿？这东西是谁造的？它有什么用？” Henney 敏锐地指出，这完全就是现代企业遗留系统（Legacy System）的写照：没有人知道是谁写的，也没有人清楚具体怎么运行，但“一年之中总有那么两次，它对齐了天象，吐出了正确的结果”，于是大家的工作就变成了小心翼翼地维持它。这种巨石系统在古希腊语中被称为“Monolithos”（单块巨石）——难以搬动，无人知晓其原理，人们只能在上面继续堆叠地衣，或偶尔敲掉一个小角落。 --- ### [27:03](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=1623s) Unix 哲学、微服务与十一年的轮回周期 Henney 随后展示了他小儿子五岁时在海滩上用几块小石头精心叠成、顶端放着一片海苔的石头平衡雕塑，具有一种精致的日式审美。这种由“小石头优雅组合”的形态，正是软件架构应有的模样。许多人将这种模块化拆分视为全新理念，并将其贴上“单一职责原则（SRP）”或“微服务（Microservices）”的时髦标签。但 Henney 强调，Unix 哲学的奠基人之一 Doug McIlroy 早就提出了核心准则：“编写只做一件事并把它做好的程序。” 微服务所标榜的核心优势早在几十年前就已被系统阐述： 1. **1968 年 NATO 软件工程会议**：便提出先定义出足够小、能够达到运行状态的系统子集，以此为基础继续构建；系统必须设计为独立实现、独立测试、独立修改的模块，模块之间仅保留通信约定。 2. **1997 年 Clemens Szyperski 的《Component Software》**：将组件定义为具有契约性指定接口、仅有显式上下文依赖、可被独立部署且支持第三方组装的组装单元。 ```mermaid flowchart TD accTitle: 软件组件与架构理念的历史演进循环 accDescr: 展示自1968年以来关于小规模高内聚独立可部署组件概念的演变历程 subgraph Timeline["理念演进（约11年太阳黑子周期）"] T1968["1968 NATO 会议<br>独立模块与运行子集"] T1978["1970s Unix 哲学<br>Do one thing and do it well"] T1997["1997 组件软件<br>契约接口与显式依赖"] T2000s["2000s 面向服务架构<br>SOA 服务化"] T2010s["2010s 微服务架构<br>小规模独立部署"] end T1968 --> T1978 --> T1997 --> T2000s --> T2010s ``` Henney 调侃软件行业的概念更新就像 11 年一遇的太阳黑子活动周期，周而复始。面向服务架构（SOA）与微服务的唯一实质区别就是多了一个“微”（Micro）字；然而随着时间推移，团队的微服务逐渐膨胀成了毫服务（Milli-services）、厘服务（Centi-services），最终重新退化为庞然大物。 - 软件架构理念每隔约 11 年就会改头换面重新包装出现一次，核心主张高度一致。 - 1968 年就已经确立了“定义小规模可运行子系统、独立测试并演进”的设计策略。 - 微服务并没有凭空创造模块化或独立部署的理念，只是这一悠久原则在现代工具链下的重新呈现。 --- ### [30:03](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=1803s) 协同之难与测试交织设计 虽然 Doug McIlroy 提出了小程序的理念，但正如 John Cook 所指出的，McIlroy 原话中真正困难的是第二句话——“编写能够协同工作的程序（Write programs to work together）”。让不同的程序和模块无缝协作极其复杂，人类的沟通摩擦与设计漂移始终存在，导致系统不可避免地膨胀、失控，并充斥着各种打补丁的胶水代码（fudge code）。 针对系统的正确性保障，Henney 引用了图灵奖得主 Alan Perlis 在 1968 年 NATO 软件工程大会上的洞见： > “如果将测试与设计交织在一起，而不是在设计完成之后才引入测试，软件系统才能得到最好的设计。”（“A software system can best be designed if the testing is interlaced with the designing instead of being used after the design.” —— Alan Perlis） Henney 查阅 1968 年的会议纪要时惊讶地发现，很多业内以为诞生于 1970 或 1980 年代的现代名词，其实在那时就已正式登场。例如通常被认为出现在 1970 年代末的“中间件（Middleware）”一词，以及被广泛认为源自 1970 年代的“单元测试（Unit Test）”，全都在 1968 年的 NATO 报告中白纸黑字地出现过。现代软件工程中推崇的测试驱动或持续验证思想，本质上是对半个世纪前行业初创期深刻洞察的回归。 - 让独立程序良好协同工作是软件中最困难的环节，也是产生冗余和胶水代码的根本原因。 - Alan Perlis 在 1968 年就提倡将测试与设计紧密交织，而非事后验证。 - “中间件（Middleware）”和“单元测试（Unit Test）”这些专业术语早在 1968 年的会议文献中就已被提出。 ### [31:38](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=1898s) 测试驱动开发与“Given-When-Then”的历史回响 人们总觉得测试驱动开发（TDD）是近代敏捷运动才诞生的新鲜事物，但回溯历史就会发现事实并非如此。以 AWK 语言为例——这门由 Alfred Aho、Peter Weinberger 和 Brian Kernighan 共同创造的小巧语言，虽然如今在各种现代脚本语言的冲击下不再经常被提起，甚至在某种程度上被大家口中的 Perl 挤占了空间（Kevlin 幽默地借用朋友的话，将 Perl 调侃为“可执行的线路噪声”（executable line noise）），但 AWK 本身具有极其优雅且反直觉的执行模型，完全围绕模式匹配与目标组织。在谈及开发过程时，Alfred Aho 曾在一篇访谈中透露，他们早在 20 世纪 70 年代就已经推行了极其实格的回归测试：“我们为 AWK 的所有功能制定了严格的回归测试；我们三个人（Aho、Weinberger、Kernighan）中任何一个人要想往语言里加入新功能，必须先为该新功能编写测试。”这正是纯正的 1970 年代版 TDD。软件行业极度擅长“重新发明轮子”；虽然人们的动机和认知在深化，但如果能及早意识到这些老思想的恒定性，技术的提炼本可以走得更远。 这种对旧思想的重新包装在测试与需求描述框架中屡见不鲜。当看到台下坐着的 Dan North 时，Kevlin 提到了自己最推崇的测试与需求组织结构“Given-When-Then”。这个概念初看就像过去的用例（前置条件、触发器、后置条件），而 Jason Gorman 曾向他指出，这在本质上就是 Tony Hoare 早在 1969 年提出的计算机编程公理化基础（Hoare 逻辑）：在给定前置条件（Given）下，执行某项操作（When），必然导出后置条件（Then）。这套逻辑构成了所有形式化方法的基础，如今它化身为优秀的会话结构和测试组织范式，具备递归特性并贯穿软件开发的各层级。正如 Kevlin Henney 所感慨的那样：“我们非常擅长重新发明东西；当然，我们的动机和对事物的理解有所提升，但我们需要明白，许多被当作崭新事物来对待的想法其实并不新。” ```mermaid flowchart LR accTitle: 从公理化逻辑到敏捷测试语法的演进 accDescr: 展示1969年Hoare逻辑与现代Given-When-Then测试结构的对应关系 subgraph S1["1969 年：Tony Hoare 公理化基础"] H1["Precondition (前置条件)"] --> H2["Execution (程序执行)"] --> H3["Postcondition (后置条件)"] end subgraph S2["现代敏捷与 BDD 规范"] B1["Given (给定初始上下文)"] --> B2["When (发生特定事件/操作)"] --> B3["Then (验证预期结果)"] end H1 -.->|"概念映射"| B1 H2 -.->|"概念映射"| B2 H3 -.->|"概念映射"| B3 ``` --- ### [34:02](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=2042s) 技术债务的本意与软件的演进困境 1992 年，Ward Cunningham 创造了“技术债务”（Technical Debt）这一术语，但后人对其产生了广泛误解，以为它仅仅是指代码写得很烂。Kevlin 以按揭房贷（Mortgage）作比喻：词根“mort”意味着死亡，房贷本质上是一份抵押至死的契约，但人们依然乐于接受，因为它是结构化债务，每个月不会有人拿着大棒上门暴力催债，换来的是实实在在的住房。债务本身并不坏，关键在于如何对待它。Ward Cunningham 当时的构想是，第一次发布代码就像借债，适度借债能加快开发进度，前提是必须通过重构迅速还清。Ward Cunningham 是个对金钱非常谨慎的人，他以为用“债务”这个词就能让人本能地意识到失控的危险，却未曾预料到后来的团队会肆无忌惮地累积债务。危机的根源在于债务未被偿还：“在未完全写对的代码上所花费的每一分钟，都算作该笔债务的利息。” 软件系统的演化往往不可避免地走向混乱。正如 Alan Perlis 所总结的那样：“从长远来看，每一个程序都会演化为洛可可式，最终沦为瓦砾堆（In the long run every program becomes Rococo and then rubble）。”（洛可可风格的繁复夸张甚至让巴洛克风格看起来都显得极简）。多年来，软件行业一直幻想摆脱编程本身的繁琐，寄希望于仅靠规范说明就自动生成软件。Edward V. Berard 早在 1991 年就讽刺道：“在水上行走与根据规范开发软件都很容易，前提是两者都得处于冰冻状态（Walking on water and developing software from a specification are easy if both are frozen）。”漫画 CommitStrip 也生动刻画过这一荒诞循环：管理者宣称未来不再需要程序员，只需写好全面且精确的规格说明，程序就能自动生成；而软件行业对于“精确详尽到足以直接生成可用程序的设计规范”，历来只有一个标准称谓——那就是“代码”（Code）。 - **按揭借喻**：技术债务如同结构性贷款，用短期折中换取交付速度，但必须制定偿还计划，否则持续的利息支出会拖垮整个开发进程。 - **神圣规范的迷思**：试图绕过编码直接靠规格说明书自动生成软件的妄想，至少从 1950 年代开始就以不同的形式每隔十年卷土重来一次。 --- ### [36:47](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=2207s) 编程是设计活动，而非生产制造 1992 年，Jack Reeves 在《C++ Report》（即《C++ Journal》）上发表了一篇具有里程碑意义的文章《What Is Software Design?》（什么是软件设计？），成为后来软件工匠精神（Software Craftsmanship）运动的核心基石。Jack Reeves 深刻指出，数十年来整个行业最大的误区，就是把编程当成一种非智力的、流水线式的“生产制造活动”，而忽视了它实质上是一项“纯粹的设计活动”。其他工程学科之所以对软件行业心生羡慕，正是因为软件行业早已在无形中彻底解决了“生产制造”难题。 这一真知灼见甚至可以回溯得更早。在 1968 年首届北约软件工程会议（NATO Software Engineering Conference）上，Peter Naur 与 Brian Randell 便明确写入报告：“复制一个软件系统的多份副本，是软件制造中对应于其他工程领域生产制造阶段的环节；它仅仅通过简单的复制操作来完成，并且仅占软件制造成本的极小一部分。”软件的“生产阶段”本质上是编译与文件拷贝，成本趋近于零；而写代码的过程，全过程都属于传统工程中的“工程设计阶段”。如果管理层错误地用管理制造业流水线的方式去管理软件设计活动，必然会导致系统性灾难。 --- ### [38:27](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=2307s) 模块化、易变性与面向对象的本质 关于如何组织设计活动与划分系统结构，David Parnas 在 1972 年关于模块化的开创性论文中给出了经典答案。如今 Java 等生态圈又重新兴奋于模块化概念，仿佛刚刚发明新技术一样。然而 David Parnas 早在数十年前就指出，系统分解绝不应当仅仅按照业务领域概念聚类，或者照搬数据范式，而是应当始于“一份困难的设计决策列表，或者可能发生变化的设计决策列表”：“每个模块的设计目的，都是向其他模块隐藏这样一个决策（Each module is then designed to hide such a decision from the others）。”这种设计视角的精髓在于防范“易变性”（Volatility）与不稳定性，避免改动一处牵扯全身的高昂经济代价。当开发团队就某种架构方案产生分歧、或者面临未知技术选型时，最佳策略就是用模块边界将该分歧或不确定性包裹隔离开来。 关于高内聚与低耦合的理论，同样在半个世纪前就已经被透彻阐述。Kevlin 展示了自己在波特兰鲍威尔书店（Powell's Books）淘到的一本 1970 年代经典结构化设计书籍（封面带有浓厚的时代嬉皮迷幻色彩）。书中明确定义：内聚度衡量的是模块内部各元素关联强度的指标，高内聚模块是一组因关系极其紧密而必须视作一个整体的语句与数据项，任何强行拆分的企图只会导致耦合度增加和可读性下降。 谈及现代各种编程范式的误读，面向对象（OOP）是首当其冲的重灾区。Alan Kay 曾明确澄清过自己心目中面向对象的真正含义：“它仅意味着消息传递、状态过程的局部保留与保护隐藏，以及对所有事物极其极端的延迟绑定（It means only messaging, local retention and protection and hiding of state process, and extreme late binding of all things）。”面向对象在其最初的设计构想中，内核是一个彻底的消息传递系统，而非后人所执迷的静态类继承体系。 ### [41:45](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=2505s) 并发与同步的谬误：从线程共享到消息传递 在讨论现代并发模型时，Kevlin Henney 引用了 Russell Winder 在《97 Things Every Programmer Should Know》中的经典观察：与其把“线程与共享内存”作为核心编程模型，我们完全可以使用“进程与消息传递”。这里的进程并非专指重量级的操作系统进程，而是指拥有受保护独立状态和可执行代码的执行单元。像 Erlang 以及更早的 Occam 这类语言早就证明，进程是构建并发和并行系统极其成功的机制，它们根本不需要面对共享内存多层架构中令人窒息的同步压力。 Henney 回忆道，软件行业曾经陷入了一种“给所有代码塞进线程”的狂热，主流编程语言和核心库争先恐后地引入线程支持。以 Java 早期版本为例，Henney 注意到其仅有的几个基础集合类竟然全部设计了 `synchronized` 接口。他当时就觉得设计者根本不知道自己在做什么——多线程编程中最不应该做的事情，恰恰是在线程之间直接共享基础集合类。盲目引入线程只是因为它“听起来很酷”，而这种做法留下的遗产只有满地的顾问账单和排查不完的 Bug。 很多人误以为使用线程和锁能提升性能，但同步的本质恰恰相反。Henney 幽默地指出，计算机等待的速率是完全恒定的，3GHz 的 CPU 等待起来也是 3GHz，多核 CPU 也不过是一起等待罢了。同步的目的正是为了消除并发，因此借由加锁来实现加速完全是逻辑矛盾。Kevlin Henney 一针见血地指出：“The purpose of synchronization is to eliminate concurrency.” - 同步机制的作用是阻止并发执行，在追求性能的路径上滥用锁只会让系统变慢。 - 基于消息传递的进程模型避免了共享可变状态带来的复杂竞态。 --- ### [43:45](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=2625s) 历史的回响：Actor 模型、Lisp 与 Lambda 演算的起源 当前的并发热门概念早在数十年前就已经成型。Carl Hewitt 早在 1970 至 1973 年间就提出了 Actor 模型；基于通信顺序进程（CSP，Communicating Sequential Processes）的 Occam 语言，其理论源头也是 Tony Hoare 在 1970 年代的研究。Henney 分享了自己的经历，他在攻读硕士学位期间的研究方向正是 Actor 模型，并且是基于 Lisp 构建的面向对象 Actor 系统。 这也揭示出面向对象与函数式思想之间的深刻联系。Alan Kay 曾明确表示，Smalltalk 的灵感极大程度来源于 Lisp——用极少数的核心原语组合出庞大系统的“概念极简主义”（economy of ideas）。业界常常政治性地争论 Actor 模型究竟算不算面向对象，Henney 指出按照 Alan Kay 最初的定义，Actor 就是标准的面向对象模型，根本毫无争议。 更进一步，Luca Cardelli 与 Peter Wegner 在 1984 年发表了关于数据抽象的论文；William Cook 后来在重温该理论时提出过一个极具冲击力的论点：Lambda 演算其实是历史上第一个面向对象语言。Cook 将其溯源到 1941 年，而 Henney 深入考证后发现 Alonzo Church 提出 Lambda 演算甚至可以追溯到 1932 年。Henney 戏谑地回顾了语言社区的发展：Java 程序员在 2014 年因为引入 Lambda 欢呼雀跃；C++ 程序员轻蔑地说自己 2011 年就有了；JavaScript 程序员也在争论；而 Lisp 和 Algol 早在 1960 年代甚至更早的 1932 年就实现了这一切。Kevlin Henney 调侃道：“It’s kind of really sweet when you know you got Java programmers getting terribly excited in 2014 going, ‘Yeah, we've got lambdas!’” ```mermaid flowchart LR accTitle: Evolution of Core Programming Concepts accDescr: A timeline mapping foundational concepts from Lambda calculus to modern paradigms like OOP and Actor model. subgraph Foundations ["理论基石 (1930s-1970s)"] L["1932: Lambda 演算<br/>(Alonzo Church)"] CSP["1970s: CSP 理论<br/>(Tony Hoare)"] Actor["1973: Actor 模型<br/>(Carl Hewitt)"] end subgraph Evolution ["语言演进 (1960s-1980s)"] Lisp["1960s: Lisp / Algol"] Smalltalk["Smalltalk<br/>(Alan Kay 消息传递)"] Occam["Occam / Erlang<br/>(进程与消息)"] end subgraph Modern ["现代工程落地 (2010s)"] Lambdas["现代 Lambda 支持<br/>(C++11, Java 8)"] Microservices["微服务 / 并发框架"] end L --> Lisp Lisp --> Smalltalk Smalltalk --> Lambdas CSP --> Occam Actor --> Occam Occam --> Microservices ``` --- ### [46:04](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=2764s) 范式的无界流动与协调模型 当大家争论哪种编程范式才是“最好”的时候，Henney 借用 Haskell 的核心设计者 Simon Peyton Jones 的观点给狂热的函数式程序员泼了冷水：“Excel is the world's most popular functional language.” 许多人不得不面对一个尴尬的事实：财务部门的会计人员写函数式程序的时间，可能比软件工程师还要长得多。 软件的核心往往不在于范式本身，而在于范式是如何被落实与执行的。编程范式之间并不是泾渭分明、由高墙阻隔的孤岛，而是一片没有边界、连续流动的疆域。为了将计算逻辑组合为更大的系统，架构师需要一种统领全局的哲学。早在 1990 年代初，David Gelernter 和 Nicholas Carriero 就提出了“协调语言”（Coordination Languages）的概念，将完整的编程模型解耦为两大部分： 1. **计算模型（Computation Model）**：由独立的、高内聚的组件负责执行具体且定义明确的计算任务。 2. **协调模型（Coordination Model）**：专门负责将各个计算单元编织、连接与通信起来。这种关注点分离思想正是现代微服务架构和框架设计的核心。 --- ### [48:02](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=2882s) 管道隐喻、历史的复用与闭幕反思 在寻找最古老的协调模型时，Henney 呼应了本次大会上多位演讲者的共同参照物——Unix 管道。早在 1964 年，Doug McIlroy 就构想出这种类似花园浇水水管的机制：当需要以另一种方式处理数据时，只需再拧上一段水管。这不仅是 I/O 的本质，更是一种串联式（concatenated）、函数式的数据流模型。计算单元不需要等待整体终止，而是以持续流式的方式处理数据。讽刺而幽默的是，尽管该理念在 1964 年就已经成型，Unix 团队直到 1970 年才由 Ken Thompson 在键盘上“找到”并正式实现了竖线 `|` 这个管道符号。 在演讲尾声，Henney 讲了一个讽刺却发人深省的真事：他多年前合作过一位同事，每次业界涌现出所谓的新技术范式，那位同事就会打开自己同一份销售 PowerPoint 幻灯片，执行一次全局“查找与替换”——把 `Object` 换成 `Component`，把 `Component` 换成 `Service`，再把 `Service` 换成 `Microservice`，然后拿着它去向客户兜售。 Henney 总结道，这种经久不衰的幻灯片固然令人感到讽刺，但也恰恰揭示了底层技术的恒定与本质。软件行业所掌握的核心思想远比大家自以为的要深厚得多。如果从业者能够具备历史认知，了解过去数十年早已沉淀的智慧，就能在面对宣称“全新”的技术概念时，一眼辨别出什么是真正的创新，什么是换汤不换药的旧词重提，从而避免在不断重新发明轮子的循环中白白消耗精力。Kevlin Henney 总结道：“Brilliant as our progress has been, we might be even better if we paid attention to the things in the past so we could understand when a new idea comes along what is genuinely new about it and focus on that rather than getting distracted by repeating the same message.” - 1964 年 Doug McIlroy 提出类似水管对接的程序耦合构想，1970 年 Ken Thompson 在系统中正式实现管道符号 `|`。 - 架构的本质常年保持不变，概念从对象演进到组件、服务再到微服务，其核心都在于计算与协调的解耦。 ## Notable quotes > [41:45](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=2505s) The purpose of synchronization is to eliminate concurrency. — Kevlin Henney > [08:09](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=489s) It is far better to have an under-featured product that is rock-solid, fast and small. — Kevlin Henney > [13:51](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=831s) 在软件领域，最致命的事情莫过于几乎人人都遵循的那个观念：你先详尽规定要做什么，然后再去做；这就是我们绝大多数麻烦的根源。 — Douglas Ross > [30:03](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=1803s) 如果将测试与设计交织在一起，而不是在设计完成之后才引入测试，软件系统才能得到最好的设计。 — Alan Perlis > [23:57](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=1437s) 鉴于对合理效率与表达能力这两个存在部分冲突的需求，尺寸约束不仅促成了精炼节约，更带来了一种设计的优雅。 — Dennis Ritchie & Ken Thompson > [34:02](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=2042s) 在水上行走与根据规范开发软件都很容易，前提是两者都得处于冰冻状态 — Edward V. Berard > [46:04](https://www.youtube.com/watch?v=AbgsfeGvg3E&t=2764s) Excel is the world's most popular functional language. — Simon Peyton Jones ## Mentioned Kevlin Henney, André Gide, William Shakespeare, Lisp, Algol 68, Simula 67, Brian Foote, Dick Gabriel, Ward Cunningham, Perl, MediaWiki, Wikipedia, Andy Kinslow, NATO Software Engineering Conference, Margaret Hamilton, Douglas Ross, Winston Royce, Douglas Engelbart, Alan Kay, Smalltalk, Adam Drake, Hadoop, Edsger W. Dijkstra, John Lions, Bell Labs, AT&T, Dennis Ritchie, Ken Thompson, Doug McIlroy, Clemens Szyperski, Alan Perlis, John Cook, Alfred Aho, Peter Weinberger, Brian Kernighan, AWK, Dan North, Jason Gorman, Tony Hoare, Jack Reeves, Peter Naur, Brian Randell, David Parnas, Russell Winder, Erlang, Occam, Carl Hewitt, Luca Cardelli, Peter Wegner, William Cook, Alonzo Church, Simon Peyton Jones, David Gelernter, Nicholas Carriero ## Video description This presentation was recorded at GOTO Chicago 2018. #gotocon #gotochgo http://gotochgo.com Kevlin Henney - Programming+Patterns Practice+Process @KevlinHenney ABSTRACT Everything is changing. Everything is new. Frameworks, platforms and trends are displaced on a weekly basis. Skills are churning. And yet... Beneath this seemingly turbulent flow there is a slow current, strong and steady, changing relatively little over the decades. Concepts with a long history appear [...] Download slides and read the full abstract here: https://gotochgo.com/2018/sessions/371 RECOMMENDED BOOKS Kevlin Henney & Trisha Gee • 97 Things Every Java Programmer Should Know • https://amzn.to/3kiTwJJ Kevlin Henney • 97 Things Every Programmer Should Know • https://amzn.to/2Yahf9U Henney & Monson-Haefel • 97 Things Every Software Architect Should Know • https://amzn.to/3pZuHsQ Henney, Buschmann & Schmidt • Pattern-Oriented Software Architecture Volume 5 • https://amzn.to/3GAPzN7 https://twitter.com/GOTOcon https://www.linkedin.com/company/goto- https://www.instagram.com/goto_con https://www.facebook.com/GOTOConferences #fundamentals #programming #SoftwareArchitecture #KevlinHenney CHANNEL MEMBERSHIP BONUS Join this channel to get early access to videos & other perks: https://www.youtube.com/channel/UCs_tLP3AiwYKwdUHpltJPuA/join Looking for a unique learning experience? Attend the next GOTO conference near you! Get your ticket at https://gotopia.tech Sign up for updates and specials at https://gotopia.tech/newsletter SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily. https://www.youtube.com/user/GotoConferences/?sub_confirmation=1 [Source](https://www.youtube.com/watch?v=AbgsfeGvg3E)

[41:45] Kevlin Henney: The purpose of synchronization is to eliminate concurrency. [8:09] Kevlin Henney: It is far better to have an under-featured product that is rock-solid, fast and small. [13:51] Douglas Ross: 在软件领域，最致命的事情莫过于几乎人人都遵循的那个观念：你先详尽规定要做什么，然后再去做；这就是我们绝大多数麻烦的根源。 [30:03] Alan Perlis: 如果将测试与设计交织在一起，而不是在设计完成之后才引入测试，软件系统才能得到最好的设计。 [23:57] Dennis Ritchie & Ken Thompson: 鉴于对合理效率与表达能力这两个存在部分冲突的需求，尺寸约束不仅促成了精炼节约，更带来了一种设计的优雅。 [34:02] Edward V. Berard: 在水上行走与根据规范开发软件都很容易，前提是两者都得处于冰冻状态 [46:04] Simon Peyton Jones: Excel is the world's most popular functional language.

[33:54] Edward Berard: Walking on water and developing software from a specification are easy if both are frozen. [18:59] Kevlin Henney: If anybody ever gives you the option to not put something out on the network, take it. [33:54] Ward Cunningham: Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. [26:36] Kevlin Henney: The difference between services and microservices is the word 'micro'. [33:54] Alan Perlis: In the long run, every program becomes rococo, and then rubble. [5:56] Kevlin Henney: We are uncovering better ways of developing software by seeing how others have already done it. [36:47] David Parnas: We propose that one begins with a list of difficult design decisions or design decisions which are likely to change.

[0:00] [Music] [0:15] yet there are actually gonna be no fail [0:17] screens in this talk just for variety so [0:22] we have this rather interesting [0:24] situation and anybody who's been around [0:28] for more than a few years and taking a [0:32] step back and looked at the trends will [0:35] notice the underneath constant change [0:38] there is a kind of silent and very [0:41] steady continuity and constant lack of [0:46] change and so this is the premise here [0:49] oldest in you you I find that I although [0:54] I'm not necessarily keeping up to date [0:56] with every single technology because [0:58] that's actually not possible anymore [1:00] what I find is that I can actually have [1:04] an informed understanding of a [1:06] surprising amount of things by saying [1:08] what is that what is what is this like [1:10] and therefore what are the differences [1:11] what are the things I actually need to [1:13] concentrate on and you also find that [1:15] you're able to then pass on these pearls [1:17] of wisdom and do God never seen that [1:20] before and you can go yeah yeah it's a [1:21] really new idea back in 1972 or this was [1:25] 1974 and this kind of thing so this is [1:28] why don't we explore and Al Rashid it's [1:32] lovely [1:33] quote everything has been said before [1:35] but since nobody listens we must also [1:38] and we must always start again because [1:40] there's something else in software that [1:42] we are particularly bad at we have a [1:43] very weak sense of history so it is not [1:46] simply that we keep rediscovering and [1:48] reinventing the wheel and eventually we [1:50] might actually make it round [1:52] it's that we have a very poor cultural [1:55] sense of history and so are in a we live [1:59] in a constant state of astonishment and [2:00] rediscovery and I'm not saying that [2:03] that's necessarily a bad thing well no [2:06] actually maybe I am well I'll let you [2:08] decide so let's go back we're gonna talk [2:12] history let's see last week Shakespeare [2:16] day turns out that Shakespeare was one [2:19] of the first programmers and you know [2:23] this is a little-known fact [2:24] clearly the lack of appropriate hardware [2:28] in Elizabethan times was a little [2:31] awkward so to bring so he would write [2:34] these scripts and he had to use the [2:37] actor model to kind of execute them so [2:41] but many of his plays are actually [2:44] carefully disguised commentaries on [2:46] issues that we may be familiar with so [2:48] for example the tragedy of Hamlet Prince [2:50] of Denmark is actually a play that is [2:52] entirely about memory management oh you [2:58] don't believe me you're thinking oh it's [2:59] just that quote no no look here's a [3:01] failure a failure is talking about [3:04] manual memory management now I can free [3:07] tis in my memory locked and you yourself [3:09] shall keep the key of it on the other [3:11] hand Hamlet's all about garbage [3:13] collection yay from the moment table of [3:15] my memory I'll wipe away all trivial [3:17] fond records okay records okay not a new [3:20] idea there's a whole load of database [3:23] migration stuff littered across the [3:25] place so you've got this oh well you [3:30] know these days were all about garbage [3:31] collection and garbage collections are [3:32] really new idea and all the rest of it [3:33] and then somebody kind of says oh wait a [3:35] minute [3:36] Lisp Lizbeth sometimes misattributed is [3:39] a language of the 1950's its first [3:41] implementation was 1960 I'm only going [3:44] to take things that run things that are [3:46] on paper do not run solo it was sketched [3:49] out in the late 50s the first working [3:51] implementation was 1960 and that had [3:53] garbage collection was a niche thing [3:59] that was functional programming nobody [4:00] else was doing it except of course Algol [4:02] 68 and the clue to the year is in the [4:07] name so this is my copy of the Lisp [4:10] programmers manual one of my most [4:11] treasured possessions and I've got the [4:13] Algol 68 manual as well I do love a good [4:16] old book and Algol 68 at the time was [4:21] considered to be a large language too [4:24] complex and ambitious to be implemented [4:26] and is now smaller than almost any [4:29] language that you are using you can [4:31] actually find online implementations of [4:33] it Algol 68 is the most influential [4:35] language that few people have ever heard [4:37] of or used it gave us such wonderful [4:39] things as the abbreviation of int [4:41] everybody else in the 60s was happy with [4:43] the word integer but not Al Gore now [4:47] we're gonna knock that down to int we're [4:49] gonna have cha we could have long we're [4:50] gonna have shor gonna have structure we [4:52] gonna have Union we're gonna have in [4:54] fact we're gonna this is a procedural [4:56] language and it gave us you know people [4:58] often think procedural that that's just [4:59] another word for bad it's like wait a [5:02] minute so let's let's look at the [5:03] characteristics of Al Gore 68 [5:06] it was expression oriented not statement [5:08] oriented so therefore everything yielded [5:11] a value you didn't have to have two [5:13] different syntaxes for if statements one [5:16] for expressions in one photo okay this [5:17] is sounding kind of familiar it had if [5:21] and fee if you ever wondered where that [5:22] came from it came from here it allowed [5:26] you to pass around anonymous procedures [5:28] that captured their variables by closure [5:30] Oh [5:31] so in other words lambda expressions [5:33] this was procedural programming [5:34] something terrible happened in the 1970s [5:37] we shall look into that so this was [5:40] state of the art and it was garbage [5:42] collected 1967 similar 67 again the clue [5:46] is in the clue to the years in the [5:48] number and the name that had garbage [5:51] collection so this is really not a very [5:52] new idea and really what I want to [5:56] explore here is this idea of ideas that [5:59] are not you so I've got my name on a [6:01] couple of books to do with patents and [6:03] they say it's worth understanding what [6:05] patterns are a lot of people think [6:06] patterns and they think patterns they [6:08] think singleton there is a good [6:10] singleton well in fact there's two good [6:12] Singleton's there's the singleton that [6:14] attracts consultants hello I'm available [6:18] to help you with your singles and [6:20] problems and then there is the singleton [6:22] that is actually good for your code [6:23] that's this one it's a single-malt okay [6:27] and when you sip it when you have a dram [6:35] of this stuff you pause for a moment and [6:38] you think you know what has that kind of [6:41] fire rolls around your mouth maybe I [6:44] won't put that really big global [6:45] variable in the middle of my code [6:49] and you have that moment of kind of like [6:51] oneness with the universe and your code [6:54] is improved just simply through inaction [6:55] so that's the single term that you want [6:58] by the way curious observation in my [7:01] experience a system either has zero or [7:03] two or more Singleton's present one [7:06] uncanny hmm so what we're really talking [7:10] about is something a little bit deeper a [7:12] few years ago when everybody was going [7:14] through manifesto craze I got a bit [7:16] upset by their sort of it pissed off and [7:18] I was running a workshop at a cover at a [7:19] company where we were actually trying to [7:21] pull out what are your patterns not the [7:23] patterns that we find in books but if I [7:25] were to join your team on Monday what [7:28] things do you do perhaps that I am not [7:32] familiar with what's normal around here [7:34] what is your vernacular architecture so [7:37] we were looking at this so I just put up [7:39] on the on the whiteboard patents [7:40] manifesto if it had a manifest it'd be [7:42] this one we are uncovering better ways [7:43] of developing software by seeing how [7:45] others have already done it but simply [7:49] as Brian foot said patents are [7:51] aggressive disregard of originality it [7:54] is the idea that most of what we build [7:56] is unoriginal and should be the little [8:00] bit of originality is the bit that you [8:01] want to really labor at it turns out [8:03] most problems have been solved and we're [8:05] very poor at communicating those so [8:09] related to this one of the key members [8:11] of the patents community did Gabriel [8:14] wrote this book in the mid 90s his [8:17] collection of essays it wasn't just [8:18] about patterns some of his reflections [8:21] on software development software as an [8:23] industry and so on and he collected [8:26] together a number of these thoughts and [8:29] one of the more interesting ones is this [8:32] one in 1990 I proposed a theory called [8:37] worse is better now how'd you go pause [8:40] for a moment I have to do this every [8:42] time I put this slide up worse is better [8:46] is possibly the worst name that he could [8:49] have come up with it and it's there's a [8:51] sort of a its self referential in that [8:53] respect I guess there's also a sort of a [8:57] humor here and an irony one of the [8:59] hardest things in software development [9:00] is naming things correctly [9:02] we are so bad at it and this is an [9:04] example because when you hear worse is [9:07] better you think oh I'll just put out [9:08] any old crap and that'll be good enough [9:10] no that actually has a name that's [9:12] called good enough software that the [9:14] good enough school of software is [9:15] actually quite different so you need to [9:17] really understand what dick was saying [9:19] and obviously it turns out people had [9:21] really bad attention spans even during [9:23] the 90s it's not a modern phenomena so [9:27] we'll let's actually look at what he [9:28] said and let's find out what he meant by [9:29] worse it was kind of like partly a joke [9:31] partly a play if you like of why [9:34] software be more likely to succeed if it [9:35] was developed with minimal invention you [9:37] know I was take what you know and do [9:38] something else with it add the bit that [9:40] people don't know it is far better to [9:45] have an under featured product that is [9:48] rock-solid [9:49] fast and small now when most people [9:53] think worse they do not think of these [9:57] three qualities you know so yeah I'm [10:01] gonna do worse is better all right yeah [10:03] it's gonna be absolutely bulletproof [10:04] there are no bugs okay your idea of [10:08] worse is very different to my idea of [10:09] worse yeah and it's gonna be fast oh I [10:13] thought it was gonna be slow and buggy [10:14] and you know I thought it's me large and [10:18] bloated but no apparently small is worse [10:20] no the worse is a judgment on the last [10:23] aspect here rather than one that covers [10:26] what an expert will consider to be the [10:27] complete requirements it's about minimal [10:29] requirements it's about focusing on the [10:31] smallest scope and this theories [10:34] elaborated explored a number of times [10:36] throughout the decade and I was involved [10:38] in a panel that oops the two thousand on [10:41] the worse is better front but the whole [10:43] thing started back in nineteen ninety [10:44] which predates not only a jold of what [10:48] we call agile development but also rapid [10:50] application development and a whole load [10:52] of other stuff and the characteristics [10:57] simplicity and that one never goes out [10:59] of date we keep having to say it because [11:01] nobody's listening but he have an [11:05] emphasis here the design is simple in [11:07] implementation the interface should be [11:09] simple but anything adequate will do in [11:11] other words it needs to be sufficient [11:12] not stupid not terrible [11:15] but it doesn't have to be awesome [11:16] because it turns out if your [11:18] implementation is simple [11:19] then there's it has a very important [11:21] property you can discard it you can [11:24] replace it okay you can change it you [11:27] can understand it and that turns out to [11:29] be one of the most important properties [11:30] of this approach completeness the design [11:32] covers only necessary situations and can [11:35] be sacrificed in favor of any other [11:37] quality one of the classic examples of [11:40] this is Ward Cunningham's wiki the [11:45] original wiki so here's his sort of [11:47] generated purl from it is a hundred and [11:50] this is the top and tail of the original [11:52] of the original wiki Perl file it's 150 [11:55] lines of Perl for heaven's sakes I mean [11:57] that's not even like comprehensible to [11:59] humans so you know if somebody comes [12:03] across this it'll be far greater mystery [12:06] than hieroglyphics in the future I mean [12:09] it's a terrible language but 150 lines [12:13] of it you know what if you can get away [12:15] with that and I want you to just imagine [12:16] if you've got a team to do that if you [12:20] instead of getting something like ward [12:21] Connie we go oh you know what I want an [12:22] editable web I'm gonna just try this [12:24] really simple thing and I'm gonna [12:25] introduce a few conventions I only keep [12:27] it really light and it's not perfect [12:30] it's not complete but I've got it up and [12:31] running and I used to hang out a lot on [12:33] the c2 comm wiki the original wiki and [12:36] it was great it was a was it was just [12:39] enough that you need and we have [12:41] MediaWiki we've had everything has [12:43] expanded from that it's so small that [12:45] you can rewrite it it's so small you can [12:48] write your own but it's also got massive [12:51] potential for extension as as we can see [12:53] with something like there the full [12:55] infrastructure behind Wikipedia so if [12:57] you imagine offering this to a team at a [13:01] company they'd spent 18 months and not [13:04] come up with 150 lines of Perl oh my [13:07] goodness it would just it would just [13:09] dwarf any Java project you've ever [13:11] experienced so there is this thing of [13:14] like let's just start small because if [13:15] it's small enough we can change it if [13:17] it's good enough we can modify so yeah [13:22] we can keep it small correctness the [13:24] design is correct in all observable [13:26] aspects [13:27] do it do it right consistency the design [13:32] is consistent as far as it goes but it's [13:34] less of a problem because you always [13:35] choose the smallest scope first so in [13:38] other words this is actually an [13:38] incremental approach the use of the word [13:40] first here is really important you're [13:41] gonna do this you're gonna come back to [13:43] it you're gonna add things you're gonna [13:43] throw things away so this is a really [13:47] interesting kind of perspective here now [13:51] what we've just done here is discovered [13:53] the design process is initiative one you [13:56] might be thinking okay well dick was [14:00] talking back in 1990 so that was a bit [14:03] of a revelation was it No the design [14:07] process is an iterative one Andy Kinslow [14:08] that's taken from this document the clue [14:13] is in the number 1968 welcome to the [14:18] half century anniversary of the NATO [14:21] software engineering conference 50 years [14:24] how are we doing we've discovered that [14:26] design processes Initiative 1 how's that [14:28] working out for you yeah new idea to you [14:30] yeah for a lot of people it's absolutely [14:32] refreshing and yet yeah and there is [14:35] this notion sometimes people [14:36] misattribute misattribute this they say [14:40] ok this this conference in garmisch [14:45] created the term software engineering [14:47] actually know as best as we know it was [14:49] this woman here Margaret Hamilton she [14:51] worked on the Apollo flight systems and [14:53] it was in the early to mid 60's that she [14:55] coined this phrase and she developed [15:00] really kind of crazy cool ideas like [15:02] fault tolerance which actually allowed [15:04] the mission to go ahead I began to use [15:07] the term software engineering to [15:08] distinguish it from hardware and other [15:09] kinds of engineering yet treat each type [15:11] of engineering as part of the overall [15:13] systems engineering process her idea was [15:15] that engineering was everybody's at the [15:17] table ok there's kind of no hierarchy [15:20] and that was that was her perspective [15:22] but a lot of people go around wait a [15:24] minute this is all about plan driven [15:26] development isn't it isn't that what we [15:28] were taught isn't this isn't this what [15:30] the document was filled with yeah it's [15:31] filled with classic statements like this [15:33] Douglas Ross the most deadly thing in [15:35] software is the concept which almost [15:37] universally seems to be followed that [15:38] you are going to specify [15:40] you are going to do and then do it and [15:42] that is where most of our troubles come [15:44] from this was not news in 1968 this was [15:49] no great discovery we didn't have to [15:51] wait for Royce's paper in 1970 which is [15:54] often misattributed as being the origin [15:57] of the waterfall process there's the [15:59] point here is we knew this and the [16:02] hardware and the interaction that we [16:04] have in terms of program has changed [16:06] radically and yet it was already a known [16:08] thing now I'm not gonna say that [16:09] everybody knew everything back in 1968 [16:11] but when you read through the [16:14] proceedings you get a real sense of [16:15] variety of thought just as we have these [16:18] days not everybody was of one mind but [16:20] there's an awful lot of stuff on these [16:22] on these lines as I say 68 was a good [16:26] year the full joint computer conference [16:29] 1968 oh there's a lot of details in here [16:32] the one that I'm going to focus on [16:33] briefly here Research Center for [16:35] Augmented human intellect DC angle bar [16:37] this is the mother of all demos by [16:40] Douglas Engelbart very very influential [16:43] he showed crazy ideas like dynamic [16:46] linking at runtime which turns out to be [16:47] quite important for modularity video [16:50] conferencing the mouse and stuff like [16:53] that [16:54] very very influential people in the [16:55] audience included people like Alan Kay [16:58] who went on to develop smaller small [17:00] talk systems and there is this idea here [17:04] of 68 good year good year so let's go [17:07] back to the future 1990 implementation [17:11] characteristics of worse is better the [17:14] implementation should be fast turns out [17:16] that's quite important especially back [17:17] in 1968 if you're gonna write Mouse [17:19] drivers because nobody's done that [17:21] before you need things to be fast it [17:24] turns out that speed is one of the most [17:27] important critical qualities that is [17:29] overlooked because a lot of people [17:31] misunderstand the guidance on [17:33] performance let's put it this way if you [17:35] want to improve the usability of any [17:37] system making it faster gives you that [17:39] for free it's not just changing colors [17:41] you can change the colors you can move [17:42] the buttons but if you make it faster so [17:44] fast that nobody notices then you've [17:46] suddenly got an improvement in usability [17:48] you no longer have to have a debate [17:50] about what color and what logo or sim [17:53] you should use for the weight cursor [17:55] it's gone there's nothing there which [18:00] means this is interesting and that [18:03] performance should always be a concern [18:06] it's not something you do at the end [18:07] because we have no end [18:09] in an incremental approach my favorite [18:11] piece of advice from the mid-90s [18:12] remember there is no code faster than no [18:15] code until somebody invents a tachyon [18:18] pipeline in the processor and this will [18:20] remain true but we also have this other [18:22] observation going back into the 80s the [18:25] fastest IO is no IO and this is one of [18:28] the most overlooked things I did this [18:30] with a team where it turns out we got a [18:32] three-fold speed-up and something they [18:34] had managed to only get a 10% [18:36] improvement over two years simply by [18:38] eliminating unnecessary i/o it was just [18:42] a case of why why are you storing this [18:43] why we're not keeping this in memory and [18:46] this is something we need to remember [18:47] because we everybody's got this habit [18:49] these days of shoving things out on the [18:51] network so one of my favorite blogs of [18:59] 2014 was this one by Adam Drake one of [19:01] those wonderfully descriptive titles [19:03] command-line tools can be over 200 times [19:06] faster than your Hadoop cluster so he [19:08] wrote this big data well not big by [19:11] modern standards big is a moving target [19:14] big is just simply a way of oh it [19:16] doesn't fit in memory but that doesn't [19:18] sound that doesn't roll off the tongue [19:19] so we use the word big but he chose this [19:23] too gigabyte problem which you're saying [19:28] what good grief on my current laptop I [19:30] can run that in memory and still have [19:33] space to look at pictures of cats you [19:35] know but you go back to the end of the [19:37] 90s and you tell somebody you've got two [19:38] gigabytes of memory they're just gonna [19:40] sputter into their coffee and go I'm [19:42] sorry that's not happening big as a [19:45] moving target it also means your [19:46] architecture and your assumptions are a [19:48] moving target and people get into a [19:49] habit and they think oh the right way of [19:52] doing it as we did a few years ago let's [19:54] push everything out to the network [19:55] because there's cheap computing [19:56] resources there if anybody ever gives [19:59] you the option to not put something out [20:01] on the network take it okay [20:04] pushing stuff and then out of the [20:05] network when you do not need to is one [20:07] of the [20:07] best ideas you could ever have and there [20:08] is a very simple reason for this it's [20:10] called the speed of light it turns out [20:12] it's not in a config file you don't get [20:15] to change this this is not you know the [20:20] point here is that we're looking at me [20:22] I'm looking at this monitor here this is [20:23] this is about you know it's nearly three [20:26] light nanoseconds across that's actually [20:30] quite slow if you do that in terms of [20:31] cycle time my laptop is about one light [20:33] nanosecond across that gives you a cycle [20:36] time of around a gigahertz that's really [20:37] slow you put something on the other side [20:39] of the planet that's gonna be super slow [20:41] I'm not saying don't distribute but I'm [20:44] saying if anybody if unless you have a [20:45] very good reason to then don't do it and [20:47] the problem is I always got islets push [20:49] it all out and it's just like no keep it [20:51] all here you can do some great things [20:53] until somebody says this is slow we [20:55] don't have the right clearance or you [20:57] know there are other reasons then keep [21:01] this that chain that does not change it [21:04] should be small how small well [21:06] Dykstra had this in a lovely way of [21:08] looking at things my point today is that [21:09] we wish to catalyze a code we should not [21:11] regard them as lines produced but his [21:12] line spent this advice was offered in [21:15] the 1970s I was completely unaware of [21:17] this advice and spent most of the 1990s [21:19] advising people something similar and [21:21] this has not changed because it turns [21:24] out that the bandwidth problem for [21:26] software development and comprehension [21:29] is this thing that's that's the problem [21:31] can you fit it within your cognitive [21:35] bounds can I understand it therefore can [21:38] I work with it effectively the minute [21:41] you cannot do that the minute you can't [21:43] comprehend and grasp something then that [21:45] your ability to work with it drops off [21:47] dramatically it turns out that has not [21:50] changed this will never change well [21:53] actually that's not true but that's a [21:54] different talk you have to invite me [21:56] back so we see also as an aside that [22:01] this also has benefits okay let's talk [22:03] about small this is I trying to give a [22:06] kind of retro field 1980 this is Linux [22:10] this is pre Linux sorry Lions Lions John [22:13] Lyons from University of New South Wales [22:16] correctly he wanted to have an authentic [22:20] operating system for his operating [22:22] system course and at that time for [22:25] antitrust reasons a Bell Labs and AT&T [22:28] couldn't do anything with Unix so he he [22:31] used that in a year [22:32] put it in a book and annotated it or [22:34] rather he didn't put it in a book he [22:35] made a set of notes you can see on the [22:38] front it was passed around by samizdat [22:39] people would stand at photocopying [22:40] machines copying the the Lions [22:43] commentary now for those of you who too [22:45] young to know what a photocopier is it's [22:47] like a it's like a socialized form of [22:49] scanning ok and you hang around in a [22:53] university library or something you know [22:55] hoping to meet somebody interesting and [22:57] chatting whilst you're putting this [22:58] through anyway they came out in book [23:01] form and things I need to observe here [23:03] is the kernel code is in there nine and [23:09] a half thousand lines nine and a half [23:12] thousand lines gets you an operating [23:14] system I've seen classes bigger than [23:18] that and they do not do as much as an [23:23] operating system what does your system [23:26] do their domain description okay let me [23:29] translate that you take data from over [23:30] here you change the format you do some [23:32] calculations and you put the data out [23:33] over there is that about it yes okay and [23:36] you've got this big honking great class [23:38] in the middle of your system that seems [23:40] to have its own gravitational field it's [23:43] so big yeah yeah so you've got this [23:47] thing the small thing it's it's [23:49] computers have changed radically and yet [23:51] still it involves humans working on it [23:54] and when we have limits of understanding [23:57] but it turns out also if you want [23:58] creativity the worst thing you could [24:00] ever do from a creative point of view is [24:02] to take somebody imagine an artist go to [24:05] an artist and you say I'd like a picture [24:08] what off [24:09] I don't know well how big would you like [24:12] it to be owner what medium would really [24:15] like me to use I don't know you have now [24:16] got a very frustrated artist if you [24:21] start saying on a landscape I want it [24:25] this big I want you to use predominantly [24:28] the color blue [24:30] and I want you doing this suddenly [24:32] they've got something and they will [24:33] create something awesome and this [24:35] observation is true for any creative [24:39] activity as the late Dennis Ritchie and [24:42] Ken Thompson observed oh this paper was [24:44] written in 1970 there have always been [24:46] fairly serious severe sized constraints [24:48] I love the fact that always makes it [24:50] sound like it goes back a long way [24:52] yeah 1970 here we are in 1970 there [24:54] always been fairly severe cyclist range [24:56] on the UNIX OS and its software given [24:58] the partially antagonistic desires for [25:00] reasonable efficiency and expressive [25:01] power the size constraint has encouraged [25:03] not only economy but a certain elegance [25:06] of design one of the worst things you [25:08] can ever do for design quality is say we [25:09] have no boundaries you need those [25:11] boundaries they're very important [25:13] clearly they change with time but [25:15] understand what those constraints are [25:17] because otherwise you end up with stuff [25:18] like this [25:19] this is what we call a legacy system [25:23] this is I took this photograph last year [25:28] on Valentine's Day because that's how my [25:32] wife and I roll [25:33] that's romance hey it's Valentine's Day [25:36] what should we do let's take there let's [25:37] take the kids down to Stonehenge yeah [25:39] that sounds great you know forget the [25:41] roses and my kids were there they were [25:45] just they were looking at these things [25:46] I imagine get a crow or Raven on that on [25:49] that one's got a very pleased with that [25:51] so the kids were there they were looking [25:54] at the girl why I've seen pictures of [25:55] this stuff dad but I didn't realize it [25:57] with these were that big why is it here [26:00] and suddenly you realize that you're [26:02] talking about enterprise software [26:06] why is it here who built this what is it [26:11] for we don't know but twice a year it [26:13] lines up and gives the right results [26:19] it's our job to maintain it the reason [26:24] I'm talking about this is you know this [26:26] is a classic information architecture [26:28] it's yeah it's very grounded in hardware [26:30] yeah like I say computation has come on [26:33] but you know moving forward a couple of [26:36] thousand years we get to the ancient [26:37] Greeks mano lithos one stone one huge [26:45] sodding great stone difficult to move we [26:49] don't know how to move it but we just [26:51] keep adding like into it and stuff and [26:54] maybe chipping away at a corner here and [26:56] you think how do I want to build my [26:58] system in a way that is more aesthetic [27:03] so this is my youngest son a few years [27:05] ago it is about five he put this [27:08] together I was very very impressed [27:09] particularly kind of like that little [27:10] Japanese aesthetic at the seaweed on top [27:12] and you think Oh lots of small stones [27:16] elegantly composed that is what I want [27:19] that's a new idea so Doug McIlroy said [27:23] this is the UNIX philosophy right [27:24] programs that do one thing and do it [27:25] well I've got a lot of people going [27:27] around single responsibility principle [27:28] it's a really new idea no it isn't I [27:31] also showed that image to a lot of [27:33] people and they go oh I know what you're [27:35] talking about you're talking about micro [27:36] services aren't you Kevin I kind of nod [27:38] and I say if that helps you then yes I [27:40] am if that's good if that helps you [27:44] absolutely that's what I'm talking about [27:45] you know surely micro services is a new [27:47] idea well there is something in them [27:49] that is new but the problem is that most [27:51] of the virtues that people extol about [27:53] them are actually not new at all and so [27:57] here's an idea why don't we define a [28:00] subset of the system which is small [28:01] enough to bring to an operational state [28:02] then build on that subsystem [28:04] this strategy requires the system be [28:06] designed modules which can be realized [28:08] tested and modified independently apart [28:10] from the conventions for inter majek [28:11] communication so that was 1968 okay [28:17] importantly notice the [28:19] approach here the description is not [28:21] simply of let's just put things together [28:22] there is this notion of bring to an [28:25] operational state it's not a partial [28:27] system it's bring to an operational [28:28] state and everything except for the [28:31] conventions for inter modulation can be [28:33] handled and catered for we see the same [28:36] themes of rising every single decade [28:39] component software clay mr. Persky 1997 [28:42] this was already old by the time this [28:44] book came out as an idea very good [28:47] definition of a component a software [28:49] component is a unit of composition with [28:51] contractually specified interfaces and [28:52] explicit context dependencies only so [28:55] dependency management not a new idea [28:56] again and this concern a software [28:59] component can be deployed independently [29:01] in his subject to third party [29:02] composition every decade this is [29:05] beautiful cycle it's almost in tuned [29:07] with the solar cycle of sunspots it's [29:09] about eleven years this is a cycle it [29:11] goes round and round and each wave does [29:14] add something you but the point is you [29:17] need to recognize the bit that's new [29:19] rather than say ah we got this is [29:20] totally radical I mean there was this [29:21] really great idea called [29:22] service-oriented architecture and the [29:25] difference between services and micro [29:28] services is the word micro because it [29:32] turns out that when you look at the [29:33] definitions of what services are [29:35] supposed to be there kind of an awful [29:37] lot like what people are saying micro [29:39] services should be how they should be [29:40] small composable and you know you can [29:42] have a small team and you can do this [29:43] and you could you can update them [29:45] independently and and and then they grow [29:48] yeah micro is turning into milli is [29:51] turning into centi and its convention [29:52] gonna turn into micro so should be small [29:55] it should be interoperate with the [29:56] programs and tools the expected users [29:58] are already using every likes to [30:00] reinvent the universe the full quote for [30:03] Doug McIlroy is this right programs to [30:06] work together interoperation [30:09] of course John Cook made this wonderful [30:10] observation in McIlroy summary the hard [30:12] part is his second sentence right [30:14] programs to work together that is [30:16] non-trivial that is one of the reasons [30:18] that we end up with bloat and challenges [30:19] and that's a that's a human thing that's [30:21] not gonna change [30:22] so therefore exactly the same challenges [30:25] that we've always had will always be [30:27] present things get they lose scope they [30:30] drift a bit they get a bit bigger than [30:31] they should be [30:32] we we end up with a lot of fudge code [30:34] and sort of workarounds to get things to [30:37] talk to one another that's not going to [30:39] change perhaps what you what you can't [30:42] change is your awareness that that is [30:43] constant it should be bug free and if [30:46] that requires implementing fewer [30:47] features do it okay well how do we [30:50] there's many ways of ensuring that we [30:52] could we could actually try and do stuff [30:55] and make sure it works one of the things [30:57] it's a radical idea that's proven [30:59] popular I'm testing so Alan Perlis in [31:03] 1968 a software system can best be [31:05] designed if the testing is interlaced [31:07] with the designing instead of being used [31:08] after the design one of the things that [31:10] I found fascinating about reading the [31:12] software engineering proceedings from [31:15] 1968 was there were some terms that I [31:17] had I had assumed came around later [31:20] for example middleware I had originally [31:23] attributed to late 70s early 80s the [31:25] term middleware is in the document unit [31:28] tests I had attributed as a 1970s term [31:31] I'd been unable to find anything [31:32] predating the 1970s until I read this [31:35] document so this is not use you know [31:38] okay well maybe we're going to talk [31:39] about test-driven development surely [31:41] that's new so Alfred a ho [31:44] who is the a in awk hey-ho Weinberger [31:48] Kernighan awk is a lovely little [31:51] language that doesn't get as much [31:53] perhaps doesn't get as much airtime as [31:55] it used to because everybody scripts and [31:57] stuff these days but it was partly [31:59] knocked out by that abomination that [32:01] people call perl or as a friend of mine [32:03] described it executable line noise and [32:06] ork has a very elegant and [32:09] counterintuitive execution model it's [32:11] organized around [32:13] pattern matching and goals it's some [32:15] really nice little stuff and so in an [32:20] interview so it's 1970s Alfred Ayers [32:22] says we instituted a rigorous regression [32:24] test for all the features of walk any of [32:26] the three of us a home Weinberger Konya [32:28] who put in a new feature into the [32:29] language first had to write tests for [32:30] the new feature so there you go TDD 1970 [32:34] style we are very good at reinventing [32:36] stuff sure our up motivation and our [32:39] understanding of things improves but we [32:41] need to understand that a lot of these [32:44] ideas that are treated as new [32:46] or not and if we only had the ability to [32:48] recognize this kind of constancy of old [32:51] ideas we'd probably get even further [32:53] with our refinements and understandings [32:56] while we're on it [32:58] and I know Dan's in the audience given [33:00] when then my favorite way of describing [33:02] test structure as well as organizing [33:05] requirements also has echoes I remember [33:09] looking at that game I wait a minute how [33:11] I used to do use cases preconditions [33:13] triggers post conditions but it was [33:16] Jason Gorbals that tipped me off on the [33:18] fact that this is Tony horse logical [33:21] construct axiomatic basis for computer [33:26] programming 1969 given a given given a [33:30] precondition when you execute something [33:32] you get a post condition and this was [33:34] the basis of all methods but it also [33:36] turns out to be a good conversational [33:38] construct a good way of organising tests [33:40] a good it's it's recursive its present [33:43] all the way through this is not in that [33:45] sense of new idea I'm just looking [33:47] forward to the 2020s when we'll probably [33:48] find a different way of describing these [33:50] three it should use past many [33:54] subtractions as long as they don't get [33:56] in the way so don't make things too [33:57] complicated so Ward Cunningham came up [34:02] with the term technical debt that one [34:04] dates back to 1992 as a term and a lot [34:08] of people misunderstood what Ward was [34:09] saying he wasn't saying it all sucks [34:13] because I mean I have a debt my wife and [34:15] I have a debt it's called a mortgage [34:17] yeah and occlude the word mortgage is [34:19] actually in the first word first part of [34:21] it Mort death this is a deal on to the [34:24] death okay [34:25] now it turns out we got a decent [34:27] trade-off for that we've got a mortgage [34:29] it's structured debt people don't turn [34:32] up on our door with brickbats saying [34:34] give us the money every month it's it's [34:36] structured we've got a we've got a [34:39] reasonable way of repaying and in [34:40] exchange awesome we get a house so in [34:43] other words debt is not of itself bad [34:45] it's what you do with it and as far as [34:48] Warren was concerned it's a shipping [34:50] first time code is like going into debt [34:52] a little debt speeds development so long [34:54] as it is paid back promptly with a [34:55] rewrite I think Ward is very [34:57] conscientious with his money [34:59] he couldn't imagine that anybody would [35:01] say yeah let's just increase the debt he [35:04] says he that he coined it so it'd be [35:06] blindingly obvious that it's a bad idea [35:09] when you live when you leave it I manage [35:11] the danger occurs when the debt is not [35:12] repaid every minute spent on not quite [35:14] right coke counts as interest on that [35:16] debt importantly that was the origin of [35:19] this but again the observation that [35:21] sometimes it doesn't work out quite as [35:23] we hoped is dates back even further [35:28] there you got some microservices [35:30] architecture as implemented by most [35:32] companies Alan Perlis in the long run [35:36] every program becomes Rococo and then [35:38] ruble if you're not sure what Rococo is [35:40] it makes Barack look minimal that's so [35:45] we are presented once again with this [35:48] idea of like ok so how do you build a [35:49] system surely we can just specify and [35:52] it'll work it's just the programming [35:53] that's getting in the way it would bear [35:55] out 1991 I think walking on water and [35:58] developing software from a specification [35:59] or easy Botha frozen so so how are we [36:03] gonna do the specification so one of my [36:05] favorite cartoons alongside xkcd of [36:09] course is commits trip and you have the [36:11] manager talking to the coders there [36:12] someday we won't even need coders [36:14] anymore we'll be able to just write the [36:15] specification the program will write [36:16] itself [36:17] ah nobody's ever said that at all in the [36:19] history of programming going back to the [36:21] 1950s yeah again there's a regularity [36:25] maybe people could just write it and yep [36:27] yeah I watch it come around again oh wow [36:32] you're right we'll be able to write a [36:33] comprehensive and precise baton ban we [36:35] won't need programmers anymore exactly [36:36] and do you know the industry term for a [36:38] project specification is comprehensive [36:40] and precise enough to generate a program [36:43] code it's called code [36:47] you can't get much more precise than [36:49] that Jack Reeves in 92 C++ uses journal [36:53] this is actually a touchstone for many [36:55] of the craftsmanship movement and again [36:57] this is considered to be this is over 25 [37:00] years ago and there's this idea and it [37:02] wasn't necessarily new but he [37:04] crystallized it wonderfully in this [37:07] question this exploration of what is [37:09] software design programming is a design [37:11] activity now why is this important it's [37:13] important because for decades and we [37:18] continue to do it I'd like to say it's [37:19] all in the past but that's not the case [37:21] people have managed and mismanaged the [37:24] programming activity as if it were non [37:26] intellectual non design based and merely [37:29] a production activity and this idea that [37:32] it's not a production activity is not [37:34] new it turns out that we've solved the [37:38] production problem it turns out that [37:40] there are other engineering professions [37:41] that are deeply jealous now again this [37:45] is not a new insight 1968 Peter Nahum [37:47] Brian Randall the replication of [37:49] multiple copies of a software system is [37:51] the phase of software manufacturer which [37:53] corresponds to the production phase in [37:55] other areas of engineering it is [37:57] accomplished by simple copying [37:59] operations and constitutes only a minut [38:00] fraction of the cost of software [38:02] manufacture this is a profoundly [38:05] unoriginal observation but I didn't you [38:07] know but we keep going every time I [38:09] think oh it's a new observation I [38:11] remember first coming across it in the [38:12] 1990s Jack Reeves every time I look [38:15] further back there's somebody else who [38:17] said it and this is important because if [38:19] you manage the design activity you're [38:21] going to manage think very different to [38:23] managing the production activity so how [38:27] are we gonna all know stuff if it's a [38:29] program activity it's a design activity [38:30] parlous 1972 again this one is is this [38:33] one's a sort of a stand standard classic [38:36] especially everybody going into phases [38:38] and getting very excited about modular [38:40] concepts on its usual cycle the Java [38:43] folks are getting excited about this one [38:45] again having forgotten they already had [38:46] classes and stuff like that but [38:48] nonetheless Parnassus said we proposed [38:51] at one begins with a list of difficult [38:52] design decisions or design decisions [38:54] which are likely to change now notice [38:56] he's not organizing abstractions [38:59] by you know necessarily domain he's not [39:03] organizing them by this idea of how [39:07] things group and cluster or [39:08] normalization he's organizing them by [39:11] volatility by certainty by stability and [39:14] instability the recognition that changes [39:17] the only constant has always been there [39:19] and perhaps when you are creating a [39:21] software structure the one of the things [39:24] you need to care about is not simply the [39:26] cognitive bandwidth of a human being but [39:29] the economic ramifications or what [39:31] happens if we have to keep changing [39:32] everything if I have to touch everything [39:33] all of the time that's gonna be an [39:35] unsustainable activity I won't end up [39:37] touching everything all of the time I'll [39:39] just touch a few things and then [39:40] everything will localize and then we'll [39:41] end up with the Stonehenge and we'll end [39:45] up with a lot of copy and paste actually [39:46] can't do that with stones it turns out [39:48] but each module is then designed to hide [39:51] such a decision from the others this [39:53] simple observation crystallizes many [39:56] things not simply the idea of modularity [39:57] but most people overlook that his [39:59] observation was to do with volatility [40:01] you've got a team that can't agree on [40:03] design guess what [40:05] put put a boundary around that [40:07] disagreement you can actually come up [40:09] with a really simple draft of how to [40:10] structure your system based on whether [40:12] or not you agree with your colleagues [40:13] yeah based on hey we've got two ideas [40:16] for this okay we've got we've got [40:18] something there we have no idea about [40:20] this okay well there's a boundary around [40:21] that you can actually structure a system [40:23] first draft let's try that it also tells [40:26] you how your process can flow where [40:28] you're going to explore so cohesion what [40:34] am i favorable to pick this one this one [40:36] up in Powell's in in Portland people [40:39] just don't do book covers like this [40:41] anymore [40:41] and there's probably a reason for that [40:43] this is the 1970s and you know depends [40:46] on what people were taking at the time [40:47] but that does something to your eyes [40:50] cohesion is a measure of the strength of [40:52] Association of the elements inside a [40:53] module a highly cohesive module is a [40:55] collection of statements and data items [40:57] it should be treated as a whole because [40:58] they are so closely related again we've [41:00] got a different perspective on why we [41:01] glue things together and the attempt to [41:03] divide them up would only result in [41:04] increased coupling and decreased [41:06] readability [41:06] not a single concern that we expressed [41:09] now seems even remotely new [41:12] so let's talk about other things let's [41:18] talk about our understandings and [41:19] misunderstandings of paradigms okay or I [41:22] mentioned earlier on his perspective on [41:26] object orientation was this it means [41:29] only messaging local retention and [41:31] protection and hiding of state process [41:33] and extreme lake binding of all things [41:35] now what I find interesting about this [41:37] is that when you look at this it tells [41:40] you why mirror this is a messaging model [41:42] at heart and in this book that I had [41:45] just a few years back 97 things every [41:46] programmer should know russell winder [41:48] makes this very simple observation says [41:51] right okay instead of using threads and [41:54] shared memories our programming model we [41:56] can use processes and message passing [41:58] process here just means a protected [42:00] independent state with executing code [42:02] not necessarily an OS process but it [42:05] turns out these ideas are fairly old [42:07] languages such as Erlang and all come [42:09] before it has shown processes are a very [42:11] successful mechanism for programming [42:13] concurrent and parallel systems they [42:14] don't have all these synchronization [42:16] stresses that shared memory [42:18] multi-layered systems have the problem [42:19] is that we got all very excited about [42:22] adding threads to code and every sort of [42:24] said yeah let's go and add this stuff [42:25] into into our core programming languages [42:29] and core libraries and I remember when [42:31] Java came out that one of the first [42:34] things I noticed about it was that all [42:36] of the collection classes the few that [42:37] it had had the synchronized interfaces [42:41] and I remember thinking you guys have no [42:43] idea what you're doing do you because [42:45] that's not how this works you just you [42:47] the active thing you don't want to do is [42:49] to share are all the primitive [42:51] collections between threads you're just [42:54] doing threads because it sounds cool and [42:55] this is the problem the rest is history [42:58] and consultancy and bugs always remember [43:03] if you're if you're trying to improve [43:04] performance then a thread is not the way [43:10] through composing in terms of threads [43:11] and locks is not the way to do it [43:13] synchronization is the one thing you [43:15] actively want to avoid if possible all [43:17] computers wait at the same speed you can [43:21] have a three gigahertz weight you can [43:22] have multi-core weight [43:25] yeah that is the purpose of [43:27] synchronization [43:28] it is to stop the purpose of [43:30] synchronization is to eliminate [43:31] concurrency so if somebody says we're [43:33] doing threads to make things faster why [43:35] are you using locks to make things [43:36] slower hmm I sense a disturbance and [43:40] your understanding of the forces [43:41] involved so this is not new I mean the [43:45] actor model actually dates back Carl [43:46] here 1970 to 1973 [43:51] akhom which is based on communicating [43:53] sequential processes hey Tony Hoare [43:54] again 1970s as its origin I ended up [43:58] doing some stuff with with all confused [44:00] guy also ended up doing a master's [44:02] degree where my research was about the [44:05] actor model this rather than something [44:07] like early and so it's object based but [44:11] it was also built in Lisp which was kind [44:13] of interesting and this kind of brings [44:17] us around full circle because what we've [44:18] just done is we've accidentally noted [44:21] that and if we look at what Alan Kay [44:23] used to say about small talk in the [44:25] relationship to Lisp he said that it was [44:29] quite tight in the sense of the idea of [44:31] building a system where around a small [44:35] set of primitives a small set of ideas [44:38] from which you can compose something [44:39] larger he got from Lisp and that [44:42] inspired small talk was actually an [44:44] economy of ideas that went through but [44:48] the messaging model that also seems to [44:50] be interesting and people debate whether [44:52] or not actors are an object model or not [44:54] the reason they do this is because it's [44:56] politically interesting to debate it [44:58] there is no debate they are an object [45:00] model according to the original [45:02] definition from alan kay and it turns [45:05] out that lambdas also fall into this [45:07] there's a wonderful paper written in [45:09] 1984 by a car delhi and wagner about [45:13] data abstraction William cook revisited [45:15] it a few years ago saying I actually [45:17] explore the theoretical basis of this [45:20] approach and he makes this observation [45:23] Lander calculus was the first [45:24] object-oriented language and he puts the [45:27] date in 1941 so I did a bit of digging [45:29] 1932 so it's kind of it's kinda like [45:32] really sweet when you know you got Java [45:34] programmers getting terribly excited in [45:36] 2014 going yeah we've got lambdas [45:38] and you got C++ programs going like [45:40] we've got those and we got those since [45:42] 2011 [45:43] you got the JavaScript programmers going [45:45] yeah what about us and everybody else is [45:46] going yeah what about you we're talking [45:47] programming languages here right and [45:50] then and then you're sitting there and [45:53] you got all this conversation you got [45:54] Lisp and Algol sitting there going up we [45:56] had those 1960s 1932 yeah [46:00] programming like it's the 1930s however [46:04] obviously everybody gets a little bit [46:07] you know got all this is the best [46:09] paradigm this is the best paradigm I [46:10] always like to bring functional programs [46:12] down-to-earth very with this observation [46:15] from mr. Haskell silent Peyton Jones [46:18] Excel is the world's most popular [46:20] functional language it tells you that [46:23] half of the story is not the paradigm [46:26] it's how you execute it it's how well it [46:28] is carried out and it's slightly galling [46:31] to many people that people in their [46:33] accountancy Department I'm doing [46:34] functional programming for far longer [46:35] than they have but we have so many [46:38] misunderstandings it turns out that this [46:40] is a landscape without boundaries [46:42] there's a continuous flow from one [46:44] paradigm into the next they're not [46:45] bordered off maybe's build walls between [46:47] the paradigms a stupid way of thinking [46:49] so we're gonna separate everything else [46:51] apart modularity lambdas whatever it is [46:57] but we do have to put all this back [46:59] together again and that becomes our [47:01] perspective on this one we have to have [47:03] a philosophy of this and perhaps that [47:05] philosophy we like to call architecture [47:07] but there's a nice way of describing how [47:10] we should be reasoning about larger [47:12] systems and this also takes us into the [47:14] modern space when we need to start [47:15] thinking about how we compose [47:17] microservice systems how we compose how [47:19] we organize our reasoning about [47:21] frameworks back in early 90s Glencoe [47:26] talked about coordination languages and [47:28] I remember learning about this stuff [47:31] really I made a lot of sense to me this [47:33] idea of a genuine separation we can [47:35] build a complete programming model out [47:37] of two separate pieces the computation [47:39] model and the coordination model you [47:40] have nice little pieces that do nice [47:42] well-specified jobs again this predates [47:45] component thinking but that idea the [47:49] same idea the same cohesive ID [47:51] and then you have separate to that a [47:53] coordination model sometimes it helps if [47:55] it's in a different language people find [47:57] that more convenient but it doesn't have [47:59] to be but how old is the oldest [48:02] coordination model well I've noticed one [48:04] thing at this conference and I saw it in [48:06] a tweet somebody observed you know what [48:08] everybody's keeps referring to UNIX [48:09] pipes so yeah so will I 1964 Doug [48:15] McIlroy again we should have some ways [48:19] of coupling programs like garden hoses [48:21] screwin another segment when it becomes [48:23] necessary to massage the data in another [48:25] way this is the way of i/o also what you [48:28] have here is a concatenated programming [48:30] model a functional model a data flow [48:32] model and this was conceived of in 1964 [48:35] the idea of the coordination modeling [48:37] and have processes that have a very [48:39] simple input-output model continuous so [48:44] ongoing execution not termination based [48:46] execution you've run a program then it [48:47] finishes ongoing and then I can have a [48:50] coordination model the pipe it took six [48:52] years to find the pipe symbol on the [48:54] keyboard it was Ken Thompson that found [48:57] it in 1970 put it in so sometimes a good [49:00] idea takes a while to implement six [49:02] years in this case so I want to close on [49:07] this idea that we know in many ways more [49:10] than we give ourselves credit for and [49:12] that brilliant as our progress has been [49:15] we might be even better if we paid [49:17] attention to the things in the past so [49:18] we could understand when a new idea [49:21] comes along what he's genuinely knew [49:22] about it and focus on that rather than [49:24] getting distracted by repeating the same [49:27] message copying and pasting exactly what [49:29] was I mean literally copy and pasting I [49:30] worked with a guy a number of years ago [49:32] who had a same PowerPoint presentation [49:35] that every time a paradigm came along he [49:37] would get the PowerPoint presentation [49:39] and just do a global replace of whatever [49:41] word you know object for component [49:44] component to service service to [49:46] Microsoft whatever he would just do a [49:47] global replace and go out to customers [49:50] and say look this is what we're offering [49:52] you okay so the point here is that these [49:57] are the things that are timeless not [49:59] just not just the constancy of [50:01] PowerPoint that's that one level is [50:03] cynical but it's also actually [50:04] revealing but we would make much more [50:07] progress if we had this kind of [50:08] historical recognition that there do [50:10] seem to be these core ideas thank you [50:13] very much [50:15] [Applause]