How Programs Learn, and What Happens After They're Built
summary
Asserts that Brand’s 1994 How Buildings Learn and the late‑90s Big Ball of Mud paper map to software: proposes a concrete metric MTTA (how long until a code walkthrough triggers an apology), cites Building 20’s 55‑year hackable life as evidence, enumerates concrete anti‑patterns—throwaway code, piecemeal growth—and prescribes actionable practices: scenario‑buffered design, maintenance logs and a decision log to make technical debt visible and to reduce costly rewrites.
AI-written summary · about
chapters (34)
- 0:00Welcome
- 1:05Programming journey
- 2:13Talk focus beyond ML
- 2:56MTTA as code health
- 4:20Agile ideals vs reality
- 6:26Software architecture metaphor
- 7:50How Buildings Learn principles
- 9:17Adaptability in systems
- 10:41Low-road vs high-road
- 11:46MIT Building 20 case
- 13:09Libraries and rigid design
- 13:55Media Lab challenges
- 14:58Growth in software
- 15:41Designing for change
- 16:25Scenario planning
- 17:47Minimizing coupling
- 18:30Alexander’s design principles
- 19:13Big Ball of Mud origins
- 20:35Forces driving decay
- 22:41Learning from mistakes
- 23:43Invisible technical debt
- 25:31Agile scaling challenges
- 27:19Throwaway code costs
- 28:24Shearing layers
- 29:08Patterns of decay
- 29:50Worse is better
- 31:59Beck’s refactoring pitfalls
- 33:08Breaking decay cycle
- 33:51Team effectiveness formula
- 35:37Social maintenance challenges
- 36:43Scenario-buffered strategies
- 37:47Documenting decisions
- 38:50Chesterton’s fence
- 39:59Final reflections
related talks
05mLike Software, Buildings Are Made Of People
45mArchitecture
01h 01mArchitecture: The Stuff That's Hard to Change
45mSoftware Architecture for Humans!
33mSet Design: Putting the "Art" in "Architecture"
40mThe (too) many faces of architecture
24mThe too many faces of Architecture
45mArchitecture: The Stuff That's Hard to Change