How Kent Beck shapes the software engineering industry

The Pragmatic Engineer 2h28 7 min #93
How Kent Beck shapes the software engineering industry
Watch on YouTube

Summary

  • Kent Beck, a foundational figure in software engineering, reflects on a 50-year career spanning Smalltalk, design patterns, test-driven development (TDD), Extreme Programming (XP), the Agile Manifesto, Facebook’s engineering culture, and today’s AI-assisted coding; the through-line is his insistence that the human side — trust, empathy, communication, and learning — is the hardest and most important part of the work, and that technical practices only matter insofar as they serve those human needs.

The human part is the hardest part

  • Beck argues that coding is only a small part of software engineering is typing code; the rest is building understanding, trust with teammates, and confidence in the system — none of which can be automated.
  • He describes the “cosmic practical joke”: early in his career he was promised that mastering the computer was enough, only to discover decades later that success is gated by the ability to communicate, empathize, convince, and soothe other people.
  • This realization came from a position of being “10 years behind” on human skills, which shaped his later focus on practices that make human collaboration work better.

Kent’s path into tech

  • Born in Sunnyvale before it was Silicon Valley; father was an electrical engineer who brought home a 65-pound programmable calculator with Nixie tubes in the early 1970s — Beck’s first hands-on hardware, where he wrote a loop to watch the filaments count up and down for hours.
  • Read the Burroughs B6700 instruction set manual obsessively as a kid, imprinting on a stack-based architecture that later resonated with Smalltalk.
  • Father and son soldered together a 6800-based machine in the mid-1970s, programming in assembly, then BASIC.
  • Attended University of Oregon (the only school that accepted him), oscillating between computer science and music (guitar, choir) for five years plus a master’s; completed a master’s thesis on a novel query language but struggled with authority figures and “hoop jumping.”
  • First programming job came via Tektronix after he asked questions their researchers couldn’t answer during a campus visit.

Smalltalk at Tektronix and working with Ward Cunningham

  • Tektronix bet early on Smalltalk, building a workstation around it; Beck dove in, drawn by the language’s three primitives (send message, assign variable, return value) and its unification of language and UI (overlapping windows, mice, scroll bars).
  • Smalltalk let domain experts (chemical, structural engineers) build working systems themselves, even if the code underneath was a mess — a preview of today’s “vibe coding” dynamic.
  • Met Ward Cunningham; paired intensely for 6–12 months with a weekly cadence: Monday coffee to pick a problem, Tuesday–Wednesday coding, Thursday demos, Friday tech report — keyboard passing fluidly between them.
  • Built Hot Draw, a graphics editor framework with figures, handles, and drawings; the “hot” moment was seeing smooth 10 Hz animation of selected rectangles moving behind others — a breakthrough in interactive graphics at the time.
  • Used a physical thesaurus to find precise names (figure, handle, drawing) — a habit reflecting the belief that code’s primary job is communicating intent to humans.

Design patterns and CRC cards

  • Both Beck and Cunningham were influenced by Christopher Alexander’s architectural patterns (The Timeless Way of Building, Notes on the Synthesis of Form) — the idea that empowering users to make decisions within constraints creates living structure.
  • Applied patterns at Tektronix to help test engineers design their own UI: gave them a constrained pattern language (windows with panes: lists, text, waveforms) that they could implement and own, rather than waiting years for a requirements document.
  • CRC (Class-Responsibility-Collaborator) cards emerged from the challenge of visualizing object-oriented control flow: Ward proposed writing responsibilities on index cards to simulate message passing; the core design move is moving computation to where the data lives to reduce coupling.

Apple: a year on Smalltalk, then fired from the Playground project

  • Joined Apple in 1987 when Smalltalk was still rising; worked on the Mac Smalltalk port, which went nowhere because Apple’s customers wanted C/Pascal tools, not Smalltalk.
  • Moved to Alan Kay’s “Playground” project (a reactive programming language for kids) but was “horribly ineffective” — wanted to do his own thing, ignored team direction, spent a month reading OOPSLA papers instead of working.
  • Fired the day after his second child was born; didn’t even attend the OOPSLA conference he had chaired.

Testing tools: SUnit and JUnit

  • At Tektronix, testing was a status divide (A/B students programmed, C students tested); Beck, an anxious programmer, wanted automated confidence without pills.
  • After Maspar, synthesized SUnit in Smalltalk: three classes (TestCase, TestSuite, TestResult), ~12 methods — isolated, automatic tests with a result rollup.
  • Key insight: write tests in the same language as the code (Smalltalk’s ethos: if you don’t like the tools, change them — the debugger, menus, everything was malleable).
  • On a flight to OOPSLA 1997, paired with Erich Gamma to build JUnit in Java, testing itself into existence in 2.5 hours on laptop batteries; handed out floppy disks the next day — instant product-market fit.

Chrysler C3 project and the birth of Extreme Programming

  • In 1996, joined the Chrysler Comprehensive Compensation (C3) payroll project (Smalltalk + GemStone DB) with Martin Fowler and Ron Jeffries; restarted it after a week of intense change, throwing away all code and adopting a 3-week iteration cadence.
  • Synthesized everything he knew (patterns, testing, Ward’s episodes, iterative planning) and “cranked it to 11” — discarding anything not proven necessary.
  • Named it “Extreme Programming” partly to prevent Grady Booch from co-opting it: chose an unattractive, edgy moniker (like extreme sports) that implied supreme preparation enabling impossible feats.
  • XP elevated programming (fingers on keyboard) as the moment where reality meets design — not a clerical task after analysis/design.
  • Timing was exquisite: the dot-com boom needed something between waterfall and cowboy coding; XP offered discipline, iteration, transparency, tests, and frequent alignment.

Test-Driven Development (TDD)

  • TDD predates XP: as a kid, Beck read a book describing writing the expected output tape before the program — “laughed out loud” when he rediscovered it via SUnit: “Why would you write a test you know will fail?”
  • Tried it on a stack: write testPushPop, watch it fail, implement, add next test — anxiety vanished; “for the first time I feel finished and I am finished.”
  • TDD’s sweet spot: rapid alternation between doing and learning (discovery + realization); not a moral imperative — people write good software many ways.
  • TDD later faded as Beck moved on; others turned it into a “moral cudgel” (“you’re not professional if you don’t TDD”), which he rejects.

The Agile Manifesto

  • 17 methodologists met at Snowbird 2001 after years of friction with Rational Unified Process dominance; Beck had a nasty sinus infection and barely remembers the meeting.
  • Martin Fowler and Jim Highsmith stayed behind during a break and produced the core: “We value X over Y” format plus principles; Beck’s only word in the final text is “daily” (daily interaction with users).
  • Names listed alphabetically — Beck is first signatory by accident.
  • Instant excitement: the manifesto captured optionality-preserving practices for an uncertain, fast-changing world; people signed on, feeling invested.
  • Beck objected to the word “agile” — it’s indefensible (no one says “I prefer rigid development”), so everyone claims it regardless of practice; “extreme” required demonstrable skill investment.

Agile’s downside: snake oil and missing technical foundations

  • Feared the manifesto would be stripped of its technical prerequisites: without the chops to write reliable, incrementally designed, tool-building code, “agile” becomes a lie — “twice the work in half the time” only after years of hard skill acquisition.
  • Scaled frameworks sold to enterprises added bureaucracy; the industry repeated the pattern: a skilled group gets results, a larger industry sells the label without the substance.

Dot-com bust and personal crisis

  • Living in rural Oregon in 2001; had 8 months of high-rate consulting booked — all cancelled the day after 9/11, while finishing a house with big bills coming due.
  • Burned out, severe depression; identity crisis from the gap between external hero/villain projections and internal reality — “people need a hero or villain, it has nothing to do with me.”
  • Couldn’t program for years; rebuilt from Sudoku to crosswords to a small Eclipse problem — “oh, this is still fun.”
  • “Lost decade” 2002–2011 until joining Facebook.

Facebook: relearning engineering at scale

  • Joined in 2011 (age 50) for stability (five kids, college tuition) and curiosity: 700 engineers, massive scale + growth + innovation simultaneously — “a bumblebee that can’t fly according to my theories.”
  • No TDD, few unit tests; instead, layered feedback: dev machines (seconds to see PHP changes), code review, internal dogfooding, phased rollouts (blast radius limited), star-based gating, observability, incident reviews (blame-free postmortems or you’re walked out).
  • Swiss cheese model: holes in each layer don’t align, bad stuff sticks, good stuff passes.
  • Culture: opportunity-rich, little planning, no deadlines, Zuck sets direction (“make photos 4x better”), engineers self-organize; middle management had generational wealth in pre-IPO options, incentivized global optimization.
  • Beck accidentally saved $5M/year in boot camp by parallelizing photo serving — “gold nuggets on the ground.”
  • By 2017, Facebook became a utility (first 911 calls when it went down), culture shifted to scarcity.

Coaching at Facebook: “Good to Great” program

  • After a year on C++ infrastructure (not his strength), pivoted to coaching — daily 1-hour conversations with stalled-but-good engineers.
  • Program grew: coached 200+ individually, trained other coaches, “great-grand-students” by departure; HR analysis showed 2x promotion rate for participants.
  • Uncompromising style: “identify and induce productive discomfort” — “you’re screwing this up, go try this, tell me how it works.”
  • Didn’t handle politics well (operated outside L&D org), but impact was measurable.

AI and the challenges of acceleration

  • “We’re accumulating code faster than we’re accumulating trust” — trust comes from struggling to understand a domain, representing it in code, writing tests that prove understanding; prompting a genie skips all that.
  • Pace of development accelerated; pace of business hasn’t — vendors with 5-year response cycles now have months before vibe-coded replacements eat their revenue.
  • Vibe coders solve the visible tip of the iceberg (gross/net pay) but miss the submerged complexity (multi-state tax compliance, reporting) — naive replacement will hit downstream surprises.
  • Beck’s model: three phases — Explore (cheap, uncorrelated experiments), Expand (focus on what works, overcome obstacles), Extract (economies of scale, predictable tweaks).
  • For 20 years the industry lived in Extract with a playbook; genie wiped the playbook clean — “nobody knows” now; seniority meant knowing the playbook, now it means writing a new one.
  • Too soon for manifestos: Agile took 15 years of OO practice; genie changes weekly — try things, share results, build the playbook communally.

What excites Kent now

  • “I’m a tree shaker, not a jelly maker” — loves the explore phase, starting things, not polishing.
  • Current projects: Arlo (object-oriented database), B+ tree in Go faster than Rust’s for some ops, adaptive radix trees, business planning for his newsletter with genie help.
  • GitHub full of “project, project2, project3, newproject, newproject2” — pushes until genie runs out of options, then wipes and restarts with different order/primitives (markdown file, commit hook).
  • Not afraid to start over; stupid ideas sometimes work spectacularly, sometimes fail — low risk if you’re willing to discard.
  • Creative impulse back: 40 years of “too big” ideas suddenly playable; “hog heaven” making real things without the minutiae blockers (version conflicts, dependency hell) that used to stop him.
Back to The Pragmatic Engineer