How Kent Beck shapes the software engineering industry

Summary

The Pragmatic Engineer – Kent Beck: How Kent Beck Shapes the Software Engineering Industry

Host: Gergely Orosz
Guest: Kent Beck
Date: July 1, 2026

---

Overview of the Episode

This special, in-person interview tracks the sweeping, decades-long impact of Kent Beck—legendary software engineer, creator of Extreme Programming (XP), pioneer of Test-Driven Development (TDD), and co-author of the Agile Manifesto. From growing up with hardware in the '70s to present-day explorations with AI agents, Kent reflects on technical revolutions, deep cultural shifts, and the evergreen human challenges at the heart of building software.

Gergely Orosz guides Kent through personal stories, industry-defining collaborations, lessons from burnout and reinvention, and a pragmatic, contemplative look at AI’s disruptive impact. The tone is conversational, frank, and warm, with Kent’s self-effacing humor and storytelling shining throughout.

---

Key Discussion Points & Insights

---

1. The Human Side of Software Engineering

• Beyond Coding:
  Kent: “Coding is part of what you're doing, but it's only a small part... You're building confidence, you're building connections with other people, you are building your own understanding. All those things are happening while you're coding.” (02:17)
• AI & Trust:
  On the rush to AI-generated code:

  “We're accumulating code faster than we're accumulating trust. And that sense of trust comes from me struggling to understand some domain concept.” (03:18)

• Empathy’s Importance:
  Kent reflects on the "cosmic practical joke" that mastering computers alone won’t make you successful—empathy and communication are essential:

  “As young people... we were promised, okay, here's this computer and if you completely understand this computer, you'll be fine... Just kidding, understand people from a position where I was already 10 years behind.” (04:59)

---

2. Early Years: Growing Up with Silicon Valley & Smalltalk

• Early Fascination:
  Kent’s first hands-on experiences programming on massive calculators and reading mainframe manuals as a child. (06:42)
• First Programs:
  Mesmerized by Nixie tube calculators and assembling early microcomputers with his father—sparked his love for creation and experimentation. (08:20, 10:19)
• University Years:
  Oscillated between studying music and computer science at University of Oregon, recognizing the importance of finishing things (“I'm a tree shaker, not a jelly maker” – 15:05).

---

3. Smalltalk, Tektronix, Ward Cunningham, and the Invention of Modern Paradigms

• Smalltalk’s Pull:

  “Smalltalk is computer support for the creative spirit in everyone... The language pushed its own mechanisms to the absolute limit. Everything is an object in Smalltalk, including numbers.” (17:16)

• Collaboration with Ward Cunningham:
  “[We] developed both a programming style where the keyboard was going back and forth, where we were talking at multiple levels...” (26:21)
• Pattern Languages & Design Patterns:
  • Christopher Alexander’s architectural concepts directly inspired software design patterns:
    “The patterns are the constraints. You can't just make any decision. You make particular decisions at particular times based on the constraints from the decisions you've already made.” (37:51)
• CRC Cards:
  — Class-Responsibility-Collaborator cards were invented as a way to visualize object-oriented program architecture:

  “Ward came up with the idea to write down on cards, index cards, here's what's going on. ...The fundamental design move in object, in designing object oriented programs … have the computation move to where the data already lives.” (49:21-51:54)

---

4. Testing, SUnit & the Origins of Unit Testing

• The Social Divide in Testing:
  Early on, testing was for “less capable” programmers; Kent bridged the divide by inventing frameworks within the developer's language (Smalltalk). (53:43-58:25)
• SUnit, then JUnit:
  Outlined the birth of the unit testing framework and its jump to Java:

  “The inspired decision to use the same language to test as you're testing it was a natural decision because I was in smalltalk...” (58:25) “We developed Junit testing itself in itself on the flight from Vienna to Washington Dulles.” (89:00)

• On Why SUnit/JUnit ‘Stuck’:

  “It was very adversarial at that time, ... The inspired decision... was a natural decision because I was in Smalltalk and you should be able to represent anything in Smalltalk.” (58:25)

---

5. Extreme Programming (XP): Origins and Principles

• Genesis at Chrysler C3:
  Project needed radical improvement; Kent synthesized what worked into “a new style of development”—testing, pairing, iterative planning (62:46-68:11)
• Naming XP:

  “Apologies to Grady, who's a good friend now, but I didn't want Grady Booch to ever say he was doing this thing. ...Extreme sports were there. ...I kind of like the analogy with extreme sports because you have to be supremely prepared.” (68:14)

• XP’s Appeal:
  A bridge between cowboy coding and heavyweight process:

  “There's discipline to it, there's iteration to it, there's transparency to it. You have ways of steering what goes on.” (72:11)

---

6. Test-Driven Development (TDD): Insight and Impact

• Roots in Mainframe Days:
  Kent remembers reading, as a kid, about specifying expected output before writing code—planted the seed for TDD. (74:48-76:23)
• The “Stupid Idea” That Worked:

  “Why would you write a test that you know is going to fail? ...But—cool. Let's try it. ...And then there's this artifact that wasn't there before. ...Where's the anxiety? Oh, just gone.” (77:25)

• TDD’s Rise and Decline:
  Once a moral cudgel—“If you're not using TDD, you're not professional. And that's just such bullshit.” Instead, Kent emphasizes context:

  “It's not a moral decision, it's a practical decision.” (80:08)

---

7. The Agile Manifesto: Creation, Philosophy, & Disenchantment

• The Snowbird Meeting:
  Kent’s only contribution to the text: the word “daily” in “daily interaction with users”; the rest arose from lean consensus during a drug-hazed, sinus-infected retreat. (83:23-88:14)
• Immediate Impact:

  “Instant, instant. People were so excited again.” (88:18)

• On the “Agile” Label:

  “What I don't like about it... is it's not defensible. Nobody's going to say I'm not agile. ...That word not only doesn't mean anything anymore, it means something negative.” (90:56)

• Agile’s Commercialization:
  On the rise of “capital-A Agile,” certifications, and snake oil:

  “Without the foundation of technical skills, you can have the best intentions... But if you don't have the technical chops... It's like putting somebody at the top of the avalanche on a snowboard for the first time.” (92:48)

• Lesson:
  Agility isn’t free. Skills, learning, and technical excellence must underpin any flexible process.

---

8. The Lost Decade & Lessons from Burnout

• Burnout After 9/11 and the Dotcom Bust:
  Overnight loss of booked work, combined with impossible expectations and praise/blame cycles, led to depression and withdrawal. (97:18-101:23)
• Rebuilding:
  Recovery began with Sudoku, crosswords, then small programming problems:

  “Eventually I got to a programming problem. I was doing a bunch of stuff with Eclipse when it was new. I got to a programming problem and I nailed it. And I went, oh, this is still fun.” (100:56)

---

9. Reinvention at Facebook: Surprises, Systems, and Coaching

• Why Join Facebook in 2011 at Age 50:

  “These people were doing nothing that was in my books and they were running a stable site ...They were expanding users and growth was expanding dramatically, and they were innovating all at the same time. So how are these—this is a bumblebee. It can't fly according to my theories.” (104:16)

• Cultural Shifts:
  • Zero sign-ups for his TDD class:

    “The Argentinian tango class was full, the advanced Excel class was full. And no one ...not even like a pity sign up. Zero people had signed up for my TDD class.” (105:50)

  • Instead, Kent adapts—“monkey see, monkey do”—and studies, then documents, how Facebook works at scale (feedback loops, phased rollouts, culture of experimentation).
• Swiss Cheese Model of Safety:
  Multiple feedback mechanisms (dev machines, code review, phased rollout, incident review) layer safety nets, compensating for lack of unit tests. (108:24-110:23)
• Good to Great Coaching:
  Kent initiates and scales a coaching program at Facebook, helping “stalled” engineers make leaps, with measurable success (“twice as likely to get promoted” after coaching) and generational student-coach lineages. (118:06)

---

10. AI, LLMs, “Genies,” and the Future of Engineering

• The Genie Metaphor:

  “It grants wishes, but it's not actually what you want.” (127:55)

• On the AI Hype Cycle:
  Warns of over-enthusiasm (as with Smalltalk and objects) where surface-level ease conceals deeper complexity and maintainability issues.

  “You solve this much of the problem. It's the part of the iceberg you can see that you can vibe code.” (128:55, 133:43)

• Rate of Change Outpaces Business:
  Software accelerates, business processes lag:

  “The pace of development is definitely accelerated. One thing I wonder, the pace of business hasn't accelerated though and that mismatch is going to become more and more apparent.” (128:55)

• Practical Advice for Engineers:
  The old playbook is gone.

  “Nobody knows. It's not just that I don't know—nobody knows. ... The skill of writing a playbook is completely different than the skill of applying a playbook. ...For 20 years we've been up in that extractostan... Now that playbook has been wiped clean and people whose identity is ‘I know the playbook’ are now terrified.” (134:38-138:28)

• We’re Back in Explore Mode:

  “The more things we can try, the better.... It's not manifesto time yet.” (139:38)

---

Notable Quotes & Moments (with Timestamps)

• On Building Trust, Not Just Code:

  “We're accumulating code faster than we're accumulating trust.” (03:18)

• On Empathy and Growth as an Engineer:

  "Empathy. Not my natural strong suit. ... Your ability to affect change in the world is gated by your ability to communicate with, empathize with, ... other human beings." (04:59)

• On Patterns:

  "The patterns are the constraints. You can't just make any decision. You make particular decisions at particular times based on the constraints from the decisions you've already made." (37:51)

• On the Origins of TDD:

  “Why would you write a test that you know is going to fail? ...Where's the anxiety? Oh, just gone.” (77:25)

• On Extreme Programming:

  "Extreme we had. I knew that a bunch of people wouldn't like it, but that's okay." (70:14)

• On the Agile Naming Debate:

  “Nobody's going to say I'm not agile. ...That word not only doesn't mean anything anymore, it means something negative.” (90:56)

• On AI and Change:

  "My inspirational motto is—nobody knows.... The skill of writing a playbook is completely different than the skill of applying a playbook." (134:38, 138:28)

• On His Core Spirit:

  “I'm a tree shaker, not a jelly maker.” (15:05, 141:00)

• Closing Note:

  “If there's a secret sauce to what I'm doing, it's not being afraid to start over.... I'm having so much fun making things that are real.” (141:47–145:07)

---

Timestamps for Major Segments

| Timestamp | Segment | |-----------|------------------------------------------------| | 02:00 | Coding, AI, and the real work of engineering | | 06:42 | Childhood, Smalltalk, and first programs | | 17:16 | Smalltalk philosophy and technical evolution | | 25:19 | Ward Cunningham, patterns, HotDraw, CRC cards | | 53:43 | Testing, SUnit, and JUnit origins | | 62:46 | XP at Chrysler, origins of “Extreme Programming”| | 74:48 | Birth of TDD, “Try the stupid idea” | | 83:23 | Snowbird & the Agile Manifesto | | 97:18 | Burnout after dotcom bust, mental reset | | 102:35 | Facebook—culture shock, adapting, Swiss cheese | | 118:06 | Good to Great coaching, impact at Facebook | | 127:44 | LLMs, “Genies,” and accelerating AI change | | 134:38 | Advice: Nobody knows, write new playbooks | | 141:00 | What excites Kent now, tree shaker philosophy |

---

Final Thoughts

Kent Beck’s journey is a roadmap of the software industry’s own evolution: relentless curiosity, deep technical reasoning, embracing failure and reinvention, and persistent human connection as the foundation of progress. He advocates for humility in the face of rapid change, and for fearlessly trying—even “stupid”—ideas, as the only way to write the next playbook.

For modern engineers, leaders, and anyone shaping software:

• Focus on learning, not certainty.
• Embrace empathy as critical technical skill.
• The job isn’t going away—but it is always, endlessly, changing.

---

For more:
See Kent Beck’s newsletter and deep dives on tech debt, craftsmanship, and more in the Pragmatic Engineer archives.

Transcript

[Podcast Host]

Ken Beck is one of the living legends of the industry. He's greatly shaped the software engineering profession and keeps impacting it even today. But there's not been a podcast episode covering his whole career from start to present until today. In this conversation we cover how Ken grew up with computers in the 70s and how he fell in love with small talk. The origin story is behind TDD Extreme Programming and the Agile Manifesto. And while Agile the word was a mistake, lesser known stories like how he got fired from Apple, Ken's lost decade in the 2000s, and why he thinks TDD has failed, how he thinks about and uses AI, and what still excites him with coding after 40 years and many more. If you'd like to understand how True Legends was shaped by the industry and shape software engineering himself, this episode is for you. This episode is longer than most of my podcast episodes, and I do hope that you'll find that it's worth the time to listen to Kent longer than he's ever told his story in one setting before. This episode was presented by Antithesis. If you work with agents, your job is no longer just writing code, it's specifying and testing it. And antithesis is the most effective method of verifying agentic code today. This episode is brought to you by turbopuffer. A fun fact about turbopuffer is how they become the search engine for AI agents.

[Interviewer (possibly a software engineer or tech journalist)]

It seems like every week they add

[Podcast Host]

a new use case from one of the leading AI companies, RAMP, Lagora, Harvey Granola. They're all on TurboPuffer. Or as the team likes to say it, they're all puffin. TurboPuffer offers a full set of search tools, Vector search, full text search, attribute filtering, Regex, and more in one API. It's built on object storage as a sole stateful dependency, so it's extremely scalable, reliable and cheap. But it's also very fast thanks to its Intel Intelligent Caching layer. One cool thing about turbopuffer is you can have unlimited search indexes, so it's perfect for multi tenant AI applications. Build an index per tenant, data is isolated by default and you can scale without thinking about it. Here's the best part. Turbopuffuffer just announced last week that they've dropped their base price from $64 per month to $16 per month, so there has never been a better time to test it out. Head to turbobuffer.com Pragmatic Kent it's so

[Interviewer (possibly a software engineer or tech journalist)]

good to have you in person on the podcast.

[Kent Beck]

Sergei, it's great to talk to you again.

[Interviewer (possibly a software engineer or tech journalist)]

Yeah, I want to kick off with something really timely. There was this tweet going viral by Dario where he said, I quote, coding is going away first than all of software engineering. You had some things to say about it. Yeah.

[Kent Beck]

My response is that that's a statement by someone who doesn't understand software engineering. Coding is part of what you're doing, but it's only a small part of what you're doing, even if it takes up a fair amount of time. You're building confidence, you're building connections with other people, you are building your own understanding. All those things are happening while you're coding. And coding's actually a great way to cement understanding. The more you program, the more you understand the domain that you're working in. So to say, well, we're just going to pass all that off to a machine. Well, you're, that's not all there is to it.

[Interviewer (possibly a software engineer or tech journalist)]

Interesting, because one thing that is so obvious with LLMs is they just code really quickly. Right. Like it, it used to take us a lot of time to both type it out and also thinking out. But you're saying that there was thinking involved and understanding involved as well in that process. Right.

[Kent Beck]

So a couple of days ago, I, I, I saw a phrase and it really hit me that we're accumulating code faster than we're accumulating trust. And that sense of trust comes from me struggling to understand some domain concept. I get it. I represent it in the code. I write tests that demonstrate that I really did understand it and now I trust my program. But if we're programming together, that act of programming together means that we trust each other more. If we talk to someone, an eventual user, and we demonstrate that we understand their needs and we, you know, they tell us, well, I want a button that does this. And we're like, well, what problem are you really solving? And we go back and forth and back and forth. That builds human trust as well. None of that can be automated. None of that occurs if we prompt the, we get the finger guns. You know, the genie goes, yeah, it's all finished, boss. And it's like, well, hang on, finished? What's finished?

[Interviewer (possibly a software engineer or tech journalist)]

As we're talking about software engineering, you've mentioned trust, connection, understanding. You didn't mention technologies, you didn't mention programming languages. You didn't mention, wouldn't even mention refactoring. This is really interesting. You've been doing this for what, 50 plus years now? Do I understand that the human part is the hardest or most important part in software engineering?

[Kent Beck]

This is the biggest cosmic practical joke ever. As young people who, some of whom I don't understand humans very well, we were promised, okay, here's this computer and if you completely understand this computer, you'll be fine. That's all you need to do. So I set out the first part of my career just to become the best programmer that I could be because that's what it would take to be successful. And then, woo, sorry, there's this whole human side and your ability to affect change in the world is gated by your ability to communicate with, empathize with, ugh, empathy. Not my natural strong suit to convince, to communicate with, to soothe, to understand other human beings. And those are exactly the skills that I thought I didn't need to learn. So I was promised just understand the computer and then, just kidding, understand people from a position where I was already 10 years behind.

[Interviewer (possibly a software engineer or tech journalist)]

So I'd like to go back to right there, to the very beginning because so many people know you from your books, from a lot of the techniques and the techniques that you've co created

[Kent Beck]

or

[Interviewer (possibly a software engineer or tech journalist)]

made a lot more popular. Xp, tdd, a bunch of other, just small refactorings and so on. But going back, how did it all start? How did you have your first contact with computers? I know your father was an electrical engineer.

[Kent Beck]

Yeah, so my father started out as an electrical engineer. He was in the Navy in the Korean War as a radio operator. Came out of that, went to school, got an electrical engineering degree, started working in aerospace as an electrical engineer and then we moved to Sunnyvale. Silicon Valley before it was Silicon Valley. This is before the invention of Silicon. Oh, this was before, yes, before there was, this is when there were still cherry orchards on El Camino. And I was born there about the time, so I was in sixth grade. He brought home a programmable calculator which was as big as, not as big as this table. Maybe half the size of this table. Probably weighed 65 or 70 pounds. Yeah, yeah, it was 65 pounds. And it had, it had Nixie tubes. Nixie tube is, this is the before seven segment LEDs. Because LEDs hadn't been invented, you'd have a, an incandescent light bulb with 10 filaments in the shape of the numbers. And my first program was, was a loop that would just count up and down and up and down because the filaments were set one in front of the other. 0, 1, 2, 3, 4, 5, 6, 7, 8, 9. So I, I just wrote a program that would count up and down because I loved watching this go Back and forth and back and forth and back for hours. I could just.

[Interviewer (possibly a software engineer or tech journalist)]

Was mesmerizing.

[Kent Beck]

Oh absolutely. That was the first time I had my hands on any real hardware. Although I did find my dad would bring home books and I was a kind of obsessive, spectrumy kind of kid. I would obsessively read these books and I found one of them lately in during a move. The Burroughs B6700 instruction set manual. And this was a really interesting machine to imprint on early because it has a hardware stack. It wasn't register based, it was stack based. How they did that with discrete transistors, I will never know, but it's just a really interesting architecture. And that book, I would just read the pages over and over and I understood nothing, but I was just fascinated with this mechanism. So when I got an actual machine and I could play with it and something that resembled assembly language and I could get it to do stuff, I could have an idea in my head and if I understood this mechanism, I could get it to do this stuff in my head, which would spark the next idea. That's what really hooked me is, is that that creative impulse coupled with knowledge of the machine, together I could create things in the world that I wanted to see.

[Interviewer (possibly a software engineer or tech journalist)]

And this was very early 70s, right?

[Kent Beck]

Microsoft 72 maybe.

[Interviewer (possibly a software engineer or tech journalist)]

So Microsoft wasn't even founded, if not in 75. What was it like in terms of how common or uncommon were these machines? How much or little did you even think that they would go anywhere? Or was it just, just a fun thing that has just been invented?

[Kent Beck]

Probably the first wave of miniaturization was

[Interviewer (possibly a software engineer or tech journalist)]

the programmable calculator, the one that your dad brought home.

[Kent Beck]

So no, the like handheld calculators. Okay, so, so, so the big tabletop calculators was, was one thing, but then there were these little calculators. I remember my dad buying an HP35 for $400, which is, I don't have no idea how much that would be today, but a lot of money just for this little thing. It'll probably be something reversation. Yeah, yeah. So you had to keep the stack in your head. Of what order do I want to put the operands in? And you know, make sure that I stack everything and then you go plus, plus, plus and that would pop stuff off the stack. And then the HP45 came along and it was, it had its own little programming language in it and that was just like, okay, this is really, really cool. And then microprocessors started to come out and we had the Z80 and the 8008 and the 6800. And my dad and I soldered together our first 6800 based machine. Then we were programming in assembly language. Then out came basic. Then this was mid-70s. Yeah, yeah. So. So that was really. I, I was spending a lot of time working on that machine. Again, I wouldn't say I understood it at a, at an elite level, but I was fascinated and I. Everything I could learn about it made me that much more effective at that. Creative impulse, imagination of a thing in the world, execution. There's a thing in the world. And that just has always felt great for me.

[Interviewer (possibly a software engineer or tech journalist)]

And then when it came to college, you. You chose University of Oregon, right?

[Kent Beck]

Well, University of Oregon kind of chose me. Cause no, none of the other places I applied accepted me.

[Interviewer (possibly a software engineer or tech journalist)]

No way. Yep. And what did you study there? How, how did your college years go?

[Kent Beck]

Well, the first year was computer science. And so they already had a computer science. Yes, yes. We had invented computer science by then. The first year was CS and I enjoyed it, but I still wasn't a great programmer. But classes I breezed through, so I was a little bit bored. So before the start of my sophomore year, it was really hot and I was walking through the music building and there were some flyers for signing up for auditions. I thought, oh, I play guitar, let me see what I can do. Next thing I knew, I was a music student.

[Interviewer (possibly a software engineer or tech journalist)]

So. Wow.

[Kent Beck]

So I'd been playing. I started playing guitar when I was 8, kind of the end of the folk boom. Mrs. Card at a summer school class and there was a guitar laying around at our house. And so I, I went and again, just obsessed. She'd show us something and I'd go home and I'd play it until my fingers bled and come in the next day. And everybody else was kind of where they were before. But I would have mastered some picking patterns, some strumming pattern because I just played it for three, four hours. So I was very into music and in high school I was in the choir, which was the big deal. We didn't have a lot of sports at our high school, but we certainly had music. It was kind of natural that I would study music at the end of a year. Music. I missed programming, so I went back to programming. Then I went back to music so I could do my senior recital. Then I went back to programming for a master's degree in another year and finished that. And so as I say, I just ended on the wrong year. Yeah.

[Interviewer (possibly a software engineer or tech journalist)]

Cause I checked. I think it was eight years in Total that you spent at Oregon, at University of Oregon?

[Kent Beck]

Five years full time. And then I had a hard time finishing my master's thesis.

[Interviewer (possibly a software engineer or tech journalist)]

Why did you have a hard time? What was your master's thesis on?

[Kent Beck]

It was a novel query language. Not surprisingly, I did not get along with the authority figures, which is a theme of my career. Yeah, just had a hard time like checking off all the boxes and getting, getting the whole thing finished. People said, oh, you're going to be sorry if you. I was just ready to quit. Just like. Yeah, you know, this is all hoop jumping and has nothing to do with programming and I was making a good living as a programmer by then, so. Oh, but you're going to regret it if you don't get your degree, if you don't finish. You're so close and it's never, never helped me one bit as far as I can tell, so.

[Interviewer (possibly a software engineer or tech journalist)]

But you completed it?

[Kent Beck]

I did complete it. It is important to complete things that in that process, from vision of thing in the world to careful activity to the thing in the world, there has to be some finishing. Even if I'm, as the Reverend Jesse Jackson said, I'm a tree shaker, not a jelly maker. And that's definitely me.

[Interviewer (possibly a software engineer or tech journalist)]

Yeah, it's true. For your work as well also for software.

[Kent Beck]

Well, I keep switching topics. That's something that'll probably come up as we go through the various things that I've worked on.

[Interviewer (possibly a software engineer or tech journalist)]

What was your first job? It was while you were still finishing your degree the last few years you started to work as a programmer, right?

[Kent Beck]

Correct. So during that graduate student year, a team from Tektronics came down to give a presentation about the programming environment work they were doing. Tektronics was started out as an electronic test equipment company in Portland. Did well in their little niche, but they are. They opened up an industrial lab as lots of companies at that point did, to do basic research. And part of that basic research was on programming environments. They came and gave a presentation. I asked some questions they couldn't answer and so they invited me out to dinner, which led to an interview, which led to a job.

[Interviewer (possibly a software engineer or tech journalist)]

Tektronix was an interesting one because this is where you met Ward Cunningham, right?

[Kent Beck]

Yeah. So Tektronics had invested early in this crazy object oriented programming language called Smalltalk and was trying to make a commercial go of it. And I got there and looked at the, the research that had been presented down at Oregon and it kind of played itself out, but this small talk thing, wow, that's cool. Cool. So I dove Right into that.

[Interviewer (possibly a software engineer or tech journalist)]

For those of us who have not touched small talk might have heard of it. What made small talk so such a hit? What pulled you in? What is the language like?

[Kent Beck]

There's a beautiful paper called the Design Principles behind Smalltalk by Dan Ingalls, and the opening line is small talk is computer support for the creative spirit in everyone. Which had two big themes. One was a language of programming, the Smalltalk language. And another was a language of interaction. Overlapping windows, mice as pointing devices, panes, scroll bars. Those were all things that were pioneered out of the user interface. Those things are kind of ordinary today, but Smalltalk, the language was built out of a very small number of primitives. There's really only three primitives in the language. Sending a message, assigning a variable and returning a value. And that's really all that there is. And so maybe towards the end we can talk about my current projects, one of which is to build another, a new small talk from scratch, just because now that's within reach for anybody.

[Interviewer (possibly a software engineer or tech journalist)]

But what.

[Kent Beck]

What I found beautiful was that the language pushed its own mechanisms to the absolute limit. So everything is an object in Smalltalk, including numbers. You don't call a function that adds two integers. You send a message plus which is received by an integer and takes an another object as a parameter. If that other object happens to be another integer, then you add them together. This leads to interesting things like there are no control structures defined. So no. If if, then else is not part of the language, it's part of the library. Because there's a. You send the message if true with a closure to true, and it evaluates the closure. You send the message if true to false with a closure and it does nothing, it just returns nil. Everything is built out of the same kind of substrate. There's very few special cases in small talk, which means that sometimes you have to get clever to understand things like how do conditionals work? But also, when the time comes for you to build abstractions, you don't have a bunch of special cases getting in your way.

[Interviewer (possibly a software engineer or tech journalist)]

It is a different way to think, especially looking at the modern programming languages that have a. You know, the language comes with so many things built in, whether, even if we're thinking of like later languages like Kotlin or Swift, or any of them, they. They have things like control structures and reserved words.

[Kent Beck]

Why would you reserve words? How rude. The programming language should give me as much vocabulary as possible.

[Interviewer (possibly a software engineer or tech journalist)]

But I do notice that with Smalltalk, the people who have used it just get really, really passionate about it. And love using it. And I understand, doing my research, that there was a time around that time, for a few years where it started to become a lot more popular. Can you tell me why it got more popular? And then what happened? It seems to have kind of fizzled out.

[Kent Beck]

Yeah. Longer story, some of which I was not privy to, some of which comes down to business decisions. Objects were, were hopping. We'd been programming with the previous generation of languages, cobol, Fortran, C, Algol, Pascal for a long time and we were used to the kind of the constraints that those provided and along came these objects and objects were going to change everything. People were really, really excited. But you know, objects were going to make programmers so much more productive that we wouldn't need nearly as many programmers. And, and in fact.

[Interviewer (possibly a software engineer or tech journalist)]

Really?

[Kent Beck]

Yeah. And you know, it's so much easier to program with objects that ordinary people can write their own programs. They don't have to.

[Interviewer (possibly a software engineer or tech journalist)]

I've heard this recently.

[Kent Beck]

Exactly.

[Interviewer (possibly a software engineer or tech journalist)]

But seriously, like this was what they were saying or like inside of the industry, this was a thing use objects or small talk and do more with. Do more with less programmers, cheaper. The works.

[Kent Beck]

Yeah. And, and to a degree it was true. We would, people would come in. So Tektronics build a workstation. There weren't workstations. Tektronix built a workstation and started to sell it with Smalltalk bundled in it. And technical people, but in different domains like chemical engineers or structural engineers or hydraulic engineers would come in and show us the systems they built with small talk. And on the surface they looked fantastic. The solved and oh, they were so happy, so proud of their baby. You look under the underneath though, at the code and it was just a horrible, unmaintainable mess. But the fact that people could program the programs that they wanted was a significant step forward. As opposed to I'm going to write a thousand page requirements document and then wait eight years and not get what I want. Which was the alternative that we were offering at the, at the time.

[Interviewer (possibly a software engineer or tech journalist)]

So it's not the first time that we're expanding because again, if we jump to today, similar things are happening. People in different domains who could never dream of hiring a developer are now building their programs and the same thing is playing out, which is if you look under the hood, if you put your software engineering hat on and look under the hood of that mess, there's

[Kent Beck]

lots of corner cases that aren't covered. It's impossible to modify and evolve.

[Podcast Host]

Yeah.

[Interviewer (possibly a software engineer or tech journalist)]

But so far this story with Smalltalk and Tektronix selling machines that come with Smalltalk, make everyone more productive. Clearly, it pays for itself. That sounds great. But then what happened?

[Kent Beck]

There were alternatives that were easier to understand. So, for example, Smalltalk's syntax is funky. It's this keyword infix syntax. Along comes C, which was originally called C with objects. And the syntax looks familiar, even though it's. The design philosophy is entirely the opposite of Smalltalk. There's lots of mechanisms and they're very complicated, but just the fact that it was approachable, that you could. There was a compiler, because we were used to having compilers in Smalltalk. There'd be some code, you'd edit it, and now you're running with the new code. There's no compile and link step. It's of course, it's just sitting right there. And if you're in the middle of, you know, you could be editing some text and say, this doesn't work the way I want, and hit control C and you get a debugger and go down the stack and you find the code that's not doing what you want and you fix it and you continue on your way. And then you're. You're writing again. That was. That was. That level of. This is intended to be a personal computer. And part of that, that sense of ownership, was that you could see everything and you could change everything. Now it turns out if you have a hundred people working on the same program, you need to put the brakes on. Everybody can't be changing everything in incompatible ways at the same time. That just doesn't work. But in terms of this is my computer and I feel power because I understand it, I can have more ideas that I can then execute on to create things in the world. It worked great for that.

[Interviewer (possibly a software engineer or tech journalist)]

Now, while at Tektronics, you work with Ward Cunningham, who would later become the developer of the first ever wiki. He had a. A huge influence, or he helped create design patterns. He also helped with extreme programming.

[Kent Beck]

Can you tell me about what it

[Interviewer (possibly a software engineer or tech journalist)]

was like working with him and how you and him started to get into design patterns, which back then didn't exist. Right. This was something you would invent later.

[Kent Beck]

We needed to give training classes on Smalltalk and Ward had written some small talk code. We knew each other. There were probably 60 people, 80 people in the labs, so we knew each other by side. I had learned a bunch about Smalltalk working on my own projects. I was working on programming language for prologue, because logic programming was also a big deal at that time. So I implemented, I think, three different virtual Machines for Prologue, including some nice animations showing how Prologue's unification mechanism worked.

[Interviewer (possibly a software engineer or tech journalist)]

And I guess for those who don't know, Prolog is this declarative language is a very different way of thinking. No, no variables as I think.

[Kent Beck]

No, no, it's got varia. No variables is fp. Bach is, oh, this fp.

[Interviewer (possibly a software engineer or tech journalist)]

Sorry. But it does have some, some funky stuff. I, I, I used it a long time ago.

[Kent Beck]

It's fun. Turns out to be difficult to write big programs in, but it's, it's, it's a good exercise because you there, there aren't control like do this thing, then do this thing, then do this thing. It's, it's more like a theorem prover. So I was working on that. Ward had built this example code for the Smalltalk class and he said, I just want to run you through this code. So I sat down next to him and he showed me the code for plumbing, called plumbing. And I suggested some improvements. We gave the class together. I met some people who would later become lifelong friends in that class. And then we just kind of fell into a rhythm of whoa, I wonder if we can make small talk do this. Because the universe of what it meant for a computer to support programming was just exploding. We had this high resolution screen which nobody had ever had before. We had this dynamic language, including our own implementation of it, so we could tweak it if we needed to. And we just didn't know what was even possible. So at first. And Ward was always a much better programmer than I was in terms of low level technique. He also had a gift for design at a higher level and a gift, as you see in the Wiki, of picking powerful top level goals and then making something that does that. But I was this 24 year old punk with attitude and he didn't let me touch the keyboard. For a while I could watch him. And then eventually I was like, those parentheses don't balance. You need a period here. And I was actually being useful to him even though, and I was absorbing watching a master programmer work, but I wasn't really driving stuff. Eventually though, I started, you know, understanding the low level patterns and then building up to the next level and the next. And then I would say, well, why is this called this and not that? And we'd pull out a thesaurus and look it up and find just the right word for things and then can you continue? And eventually I started making suggestions that he wouldn't understand right away. And so I would take the keyboard for a little while, say, lay Something like this. Oh, I get it, I get it. And then he'd take the keyboard back. Over the course of a few months, we developed both a programming style where the keyboard was going back and forth, where we were talking at multiple levels. You know, we talk about, here's this code, why isn't it working? Is this the thing we should be working on at all? What programming tools would we need for this to be easy? What should the design be? So this whole thing should work well, should we even be doing this at all? Philosophically? We would bounce between all those levels in the, in the active programming and we had a weekly cadence where Monday morning we'd have a coffee and we talk about, of the list of things because we would then out of those conversations we'd come. I wish we had a thing that did a thing. We would talk about that and then we'd say, okay, well let's go down and see how far we can get. And over and over, Tuesday, Wednesday we would make a bunch of progress on what we were working on. Thursday we'd be giving demos and refining it and Friday we'd write a tech report. So there's this whole string of tech reports that we wrote over the course of maybe six or 12 months of really working together intensely. Even if one of those weeks failed, you know, we'd have our coffee Monday, Tuesday, Wednesday, eh, this didn't work. We would know why it didn't work and what it was that we needed in order for that thing to be easy in the future. And that goes into the hopper for the next Monday's coffee. So we developed a wide range of programming tools and applications, some foundational stuff. So we had a graphics editor called Hot Draw because we had this graphical interface and everybody had been used to text interfaces for so long, but now we had high speed graphics. Oh my goodness, what can we do with this? So we kept making graphical interfaces, but it was hard to make graphical interfaces.

[Interviewer (possibly a software engineer or tech journalist)]

Yeah, I have a photo of early Hot Draw.

[Kent Beck]

Yes, absolutely.

[Interviewer (possibly a software engineer or tech journalist)]

And this reminds me when I look at Hot Draw, this, you know, like these boxes and arrows, they do remind me later of things like UML and a bunch of just the, not the exact ideas but visualizing. And of course later I think these days people don't use uml, but you still, you just go to the whiteboard and you draw out boxes and arrows and how they connect.

[Podcast Host]

Sounds like.

[Interviewer (possibly a software engineer or tech journalist)]

So you did this back in 87 or something like that.

[Kent Beck]

Correct. And because we had high performance for the time, graphics primitives, the magic moment out of Hot Draw was we drew a series of rectangles kind of on top of each other. We selected every other one. We clicked on it and we started to move it back and forth. And you could, and because we could, we could do maybe 10 hertz animation. It was, it was smooth and you could just see half of the rectangles, you know, kind of moving behind the other half. And it just, this is so hot. We were just really excited about it.

[Interviewer (possibly a software engineer or tech journalist)]

Oh, that's why, that's why you called it Hot Draw.

[Kent Beck]

That was the name, because that was the reaction to being able to see this smooth animation. And before that, writing that kind of smooth animation was a bespoke thing and took a lot of work. And with this, you subclass figure, and now you have something that works in this 2 1/2d world, and away you go. Those figures, though, were meant to represent something in the interface. It wasn't just a rectangle. It was a processor, it was a generator or it was a whatever. And then you click on it and you get these handles on the figure which, each of which represents some way to manipulate the state, not just of the graphic thing, but again, there was intended to be meaning behind it. So you'd have a handle that would raise and lower the temperature and another handle that would change the pressure or whatever, whatever domain you were working in. And then you had, it was a boxes and arrows model. So you'd have connections between things. And the connections, again, were intended to be semantic, but would follow the figures around. And actually the words figure, handle, drawing. Ward came up with those. Mine were something pedestrian. Drawing object, drawing handle. I, I, I didn't have good words for it. And this was where the, the thesaurus came in was Ward would think about, okay, this is like figures in a book. You know, we had an analogy there, there, there was a metaphor to what we were doing. But in the computer world, you can, you can have figures, figures in figures.

[Interviewer (possibly a software engineer or tech journalist)]

And do I understand that you actually had a physical thesaurus, like a book?

[Kent Beck]

Yeah, yeah. An actual book with words in it.

[Interviewer (possibly a software engineer or tech journalist)]

You would actually, as a programmer, reach for this book with words and open up to find better words all the time. Was this just you doing it or the programmers in general have, like, people that, you knew that they also have the satarasis.

[Kent Beck]

We were on the far end of the obsessive scale for this. There were other people certainly who were fighting for the right words.

[Interviewer (possibly a software engineer or tech journalist)]

But this just, this just reminds me of how programming is just more than just, you know, like writing code, how you need the skills of, for example, if you are well read, you can probably write more expressive programs. Or if you're not well read, having thesaurus. Of course you could do it online. But I assume that by opening up the book and looking through and reading a lot of other words, your vocabulary will start to grow, therefore making you a better programmer or someone who can write a lot more understandable or maintainable.

[Kent Beck]

Part of the goal of programs is to communicate intent to other human beings and now to models as well, which. Which is a much more open ended problem. We understand a lot more about how to communicate to other human beings. Whether we apply that understanding or not. We don't understand at all how to communicate effectively to models. And people are trying out all kinds of things, which is. That's great. That's what you do. Yeah.

[Interviewer (possibly a software engineer or tech journalist)]

And then later Ward went on and he got very much involved with design patterns. I can now see with Hot Draw how you know those design patterns in the Gang of Four later you see boxes and arrows. How I see some resemblance on being able to visualize objects on a monitor.

[Kent Beck]

Yes. All of the pieces were working together for us. The patterns work. I had become interested in Christopher Alexander at the University of Oregon. I couldn't afford the timeless way of building, so I read it standing up in the bookstore over the course of several visits. And Ward had also been exposed to Christopher Alexander and patterns. Alexander wanted to build, wanted buildings with a certain spirit to them. He talks about it in kind of mystical terms, but that's okay. And he hypothesized that if people made their own decisions about the design of buildings, that this spirit would exist in a way that didn't. When the architect would say, oh, well, you know, tell me what you need in a building and then I will program myself to dream of your perfect space. And then I'll tell you, I'll bring to you the solution. The way he wanted to work was to empower people to make decisions within constraints. Like me designing a house. I'm going to have roofs that fall down and walls that don't match and whatever, because I don't know. So I need constraints, but I know more about my life, so I should be the one making the decisions about, oh, family. Family dinners are really important.

[Interviewer (possibly a software engineer or tech journalist)]

Oh, so. So this is in the domain of architecture. Like. Like strictly physical buildings.

[Kent Beck]

Yes.

[Podcast Host]

Wow.

[Interviewer (possibly a software engineer or tech journalist)]

So you got a lot of inspiration from this domain. Even though software is very much a virtual that's in our head. Right. Or in the computer.

[Kent Beck]

Right. So the patterns are the constraints. You can't just make any decision. You make particular decisions at per particular times based on the constraints that come from the decisions you've already made. And that creates constraints for the next decisions that you make. We wanted that for the users of programs taking this small talk personal computer ethos to the next level. And so we were consulting on a project that wasn't going well at Tektronics. Some programmers were writing software for some test engineers, and it just, it wasn't going well. So Ward came up with the initial set of patterns that we would use for designing a user interface. Again, graphical interfaces were brand new. Nobody knew what to do. There were all kinds of crazy things coming out. In music school we learned about the evolution of musical notation. And when musical notation first came out before then it was entirely an oral tradition. Then musical notation was invented. And some of the most complicated music ever written was written in like 1200 or 1300, right after musical notation had been invented, because nobody knew what the limits were. And then, then they settled down. It was like, okay, four part motet, that's fine. We don't need to have 60 different instruments doing 60 different things all at the same time just because we can. Well, it was the same kind of way with these user interfaces. Nobody knew how to organize them. So we gave this initial set of patterns that Ward had come up with and we talked about Christopher Alexander and patterns. And I ran across a copy of Notes on the Synthesis of Form at Powell's Books in Portland and devoured that, which is kind of the theoretical underpinning of patterns. We handed the patterns to the test engineers and said, okay, we're just going to start over. Use these patterns to break your process down into windows with panes. And we were careful to only allow them to do things that we knew that we could implement. So they couldn't come up with anything. The panes had to be lists or text or waveforms. The waveforms were special, but that's okay. We could do that. Each task that you had to do in this testing process would have its own window. And so there was, you know, four or five different patterns. And they came up with an interface that was eminently implementable and they felt like they owned it. And then the Smalltalk programmers would look at that and go, okay, well, how do I implement this? How do I implement that? So that was our first foray into patterns. People get really fussed about this transfer of responsibility. They want to think, I am the designer of interfaces and I worked hard at this. And I want to ask you A bunch of questions and then I want to cogitate on that and then I'm going to bring you the solution and then you'll thank me and pat me on the head. Of course that doesn't happen. Your understanding of somebody else's problem is bounded because you're not in the middle of it. You don't have the same skin in the game. If you're not semiconductor test engineer, you don't have as much skin in the game as somebody who is. Because they're going to have to be using this interface for a long time after you're gone.

[Interviewer (possibly a software engineer or tech journalist)]

Yeah. There's also this concept of the flyby architect on teams who, you know, this very senior person has built a lot of stuff and the team is struggling. They call them and they call him or her. In this person comes, does some suggestions that kind of flies off.

[Kent Beck]

This is a seagull.

[Interviewer (possibly a software engineer or tech journalist)]

The seagull. Seagull.

[Kent Beck]

Because it should. You fly in, you make a bunch of noise, you scrap all over everything and then you fly out. Yeah.

[Interviewer (possibly a software engineer or tech journalist)]

And you drop skin in the game. Yeah. And it's interesting because we've. Anyone who's worked in teams of a certain size or certain tenure, you see it happen. And it doesn't really matter how highly skilled that person is. There might be a few exceptions, but generally if you don't have skin in the game, you just make different decisions. And then after Tektronics you worked at Apple, I only realized this about you. How did you get into Apple? This was in 1987, very exciting time from my research. How did you get in there? What did you do there?

[Kent Beck]

So Smalltalk was going up like a rocket at that time. Xerox had developed SmallTalk, it handed it to or I think companies to see can you also implement it or is this something special? So hp, Apple, Tektronix and blanking on the fourth one, HP really didn't do anything with it, but Apple and Tektronix ran with it. So Apple had its own implementation of Smalltalk and they wanted to not commercialize it in the sense of selling it, but commercialize it in the sense of having something that. This was right after the Mac had come out, something that you could use on a Mac. And so I, I knew about that project. I was getting too big for my britches at Tektronics. I, I learned a lot. You know, there's a, there's a thing, there's this kind of compression that happens when you're growing faster than the organization can recognize that you're growing but also you're not growing as fast as you think you're growing. And eventually that gap between how people see you and how you see yourself and then somewhere in between is how you really are. Those. If those gaps get too wide, you just have to move. So I was ready to move on. So I contacted Apple and I worked for about a year on the SmallTalk project which ended up going nowhere. Cause it really didn't make sense. Smalltalk could work in quite a small memory footprint. But the only developer tools Apple really needed was a C compiler, Pascal compiler,

[Interviewer (possibly a software engineer or tech journalist)]

because that's what they built their software

[Kent Beck]

on, mostly C. That's what they built their software on. That's what everybody else did. There was a thriving third market for other developer tools. But this small talk wasn't going to really do anything for anybody. Maybe school kids or something, but it

[Interviewer (possibly a software engineer or tech journalist)]

wasn't, it wasn't driving Apple sales. People who bought Apple computers typically didn't want to do small talk.

[Kent Beck]

Correct.

[Interviewer (possibly a software engineer or tech journalist)]

Correct. So we talked about the decline of small talk. I'm sensing around this time it's if, if you know, like as personal computers started spreading it's, it seems like it just remained a niche, right?

[Kent Beck]

No, it was quite strong at that time. It was growing fast. Lots of people like relative to the previous year were using it. A company had spun out of Xerox called Park Place which was selling small talk as a big ticket item for developers. And this is before there was open source out there. So the idea that you could set, you could charge money for a language implementation was a. Lots of people were doing that kind of thing and this was running out of that same kind of playbook.

[Interviewer (possibly a software engineer or tech journalist)]

Okay. So it was still doing it. It would just didn't make sense for Apple's customer base.

[Kent Beck]

Correct.

[Interviewer (possibly a software engineer or tech journalist)]

And their hardware.

[Kent Beck]

Yeah. Also though at the same time a bunch of the ex Xerox people had come to Apple. So my friend Larry Tesler was there. And by friend I mean bitter enemy who I respected a lot. Sometimes, you know, you, there are people who just raise the hair on the back of your neck. And Larry Tesler was one of those to me. And I don't know if even the feeling was reciprocated. He passed a few years ago, but so I never got a chance to talk to him. But I talked to him. You know, we, we would check in afterwards. Anyway. He was the head of the advanced technology group at Apple at that time. Alan Kay had moved to Apple and was working on a programming language for kids. Another programming language for kids called Playground Dan, Dan Ingalls was there. So a lot of the Xerox folks were, were at Apple. And I heard about Alan Kay's project and thought that was a dream of mine. Byte magazine had an article on Smalltalk. I read about the development of small talk. The project started in like 71 and it was 1980 before they released anything at all publicly. And just imagining working in that environment just seemed like heaven to me. So I moved to the Alan Kay's Playground project. Now I was horribly ineffective, ended up getting fired from that job.

[Interviewer (possibly a software engineer or tech journalist)]

No way.

[Kent Beck]

Yeah, sure.

[Interviewer (possibly a software engineer or tech journalist)]

As a programmer, you being inefficient. What happened?

[Kent Beck]

I wanted to do my own thing. And this was still, you know, I'm still in this punk mode where I'd listen to somebody else's ideas and I go, yeah, I don't think so. I have a better idea. And if you're working by yourself, that's okay, but if you're working in a team, that's not okay. So the, it came to a head. I was the program chair for the OOPSLA conference, which we probably should have mentioned earlier. There was this conference and it was the hottest conference and everybody who was anybody was there and it was growing fast and I was involved in it, kind of stumbled into it, but I was in 89, I was the program chair for Oopslop, right, for Oopsla. And I spent a month just reading papers while ignoring my duties to the playground project. And that was kind of the final straw. Okay, you're, you're not helping us, so you need to move on. And then the conference happened and my second child was busy not being born, so I didn't even get to attend the conference. But I had heard about the playground project, so I moved to the playground project and did a little bit to help build this programming language for kids. That was the next thing beyond object Oriented Programming. You would, you would call it today, you'd call it reactive programming. So you didn't. You couldn't send a message. You could only raise some condition that some other object would, would be waiting on. So it's like pub sub. But that was the only control mechanism.

[Interviewer (possibly a software engineer or tech journalist)]

And then I wanted to ask you about. This was around this time, CRC cards. What are CRC cards? I know they stand for Class Responsibility, Collaborator cards. But what were they and how did you come up with them?

[Kent Beck]

You have these imperative programs and you have a flowchart which represents accurately, if kind of verbosely, the control flow in an imperative program. Now we have these objects and you send messages which are polymorphic, so you don't know exactly what code's gonna be invoked when you send a message. And people were like, well, how do you even visualize, internalize? For me, I have kinesthetic synesthesia, so I can feel in my body, if I'm looking at some code I can feel in my body wants to go this way. It's.

[Podcast Host]

Yeah.

[Kent Beck]

Which is. Yeah, I've. I don't know if I've met anybody else who describes their experience of programming the same kind of way, but, but there we go. How do you get a sense of, however you internalize this, of what's going on in this program where you, you can't just say we execute this line and then we execute that line, because as soon as we send a message, we don't know what's going to happen. So Ward came up with the idea to write down on cards, index cards, here's what's going on. Because we would, we would talk this way all the time. So, you know, we've got a, we have a rectangle and it asks the renderer to do the thing and then that goes into the pipeline which the blah, blah, blah, blah, blah, blah, blah, blah. So we would talk with our hands a lot. So he said, well, why don't we write these things down on cards? So a big challenge in object oriented programming is dividing the responsibilities because you're moving the computation to where the data is. Saying, well, this object does this and that object does that is a really critical decision because you want the computation near to the data so that there's less coupling between them. Just a lesson that I, I think kind of got lost in the noise. That's the fundamental design move in object, in designing object oriented programs. And I, I think I stand behind that.

[Interviewer (possibly a software engineer or tech journalist)]

So, so have, have the data be close to where it's used, where the computation will happen backwards.

[Kent Beck]

Backwards. Have, have the computation move to where the data already lives.

[Interviewer (possibly a software engineer or tech journalist)]

Have the computation move to where the data is. So like if you have a rich object with the lots of data inside of it, for example, you want the computations to move there. So you want the like objects to invoke and just get the data and do whatever computation they need to.

[Kent Beck]

If I'm going to operate on stuff that's on the inside of a rectangle, like area. Yeah. Do I have height times width scattered all over the universe or do I have an area inside the rectangle that does heighten width at the limit? Now I don't care that the rectangle has height and width that's hidden from the rest of the world. Like I can represent the rectangle with two corners or I can represent the rectangle as a top left, a height and a width. To the rest of the world it doesn't matter as long as they both respond to area. So now I can come up with another representation and another representation and the rest of the world doesn't have to care if I've moved the computation where the data lives.

[Interviewer (possibly a software engineer or tech journalist)]

Yes. And that means you can have looser coupling. Correct, Understood. It's a good lesson.

[Kent Beck]

Yeah, yeah, yeah.

[Interviewer (possibly a software engineer or tech journalist)]

And, and even today, because everything that we do is under the hood, almost everything we do is object, or a lot of it is object oriented. And I don't think we think about these.

[Kent Beck]

Yeah, I see a lot of criticism of programs written in object oriented languages that aren't criticisms of object oriented programming or design.

[Interviewer (possibly a software engineer or tech journalist)]

So after Apple, you moved to a company called masspar. And the thing that I notice here is unit testing. This was the place where, as I understand you came up with something called sunit.

[Kent Beck]

While I was at Tektronics, I got interested in testing. At that point, testing was a sociological divide. If you got As&Bs in computer science school, you got to program. And if you got Cs, you had to be a tester. So it really was like a status. I'm not going to test. I'm one of these guys, not one of those. But I got interested in how would you automatically test programs? How would you get a sense of confidence in what you were doing? So I tend to be an anxious person and the more complicated my programs were, the more I had to be anxious about, the more experience I had with what kind of bugs could possibly exist, the more anxious I got. And I thought there was just some way to kind of quell this without pills. That would be great. I tried out a bunch of different approaches to writing automated tests at that point. In addition to this, this status divide, there was a tool divide. You had testing tools which would have their own kind of language in some way to connect with the program that was under test. So I tried this and that and the other thing. It was actually after MassPAR that I think this is all ancient history. So we'd have to go, you know, dig through the archeological layers. I started consulting and I was going to tell a client that they should write tests. I was going to fly out to Chicago the next day, but I didn't have any way for them to write tests. So out of these five or six experiments that I'd done. I synthesized test case, test suite and test result. That was the. It was like three classes and 12 methods. But it was a framework where you could write tests that would execute isolated from each other, fully automatic and give

[Interviewer (possibly a software engineer or tech journalist)]

you a rollup of the results of it. So this was pretty much a unit testing framework for small talk.

[Kent Beck]

It was written in. Yeah, the first version was written in smalltalk. So masspar was a Silicon Valley startup venture funded, intended to build an entire new architecture which was simd, single instruction, multiple data. So we would have a torus of process processing elements up to 16,000. So you have 16,000 in there connected in a toro toroidal grid. So you could talk to the processing elements in your left, right, up, down and diagonally. And it looks very much like the Nvidia architecture now. But this was way back when and it was just too early. So three years of that building programming environments for high performance computing. So the intention was to get the kind of performance you'd get out of a cray at that time, but for a tenth the cost. And they needed a programming environment. So we built a programming environment in smalltalk that did some really cool stuff. You could, you could single step a Fortran program and build a performance profile at the same time.

[Interviewer (possibly a software engineer or tech journalist)]

No way. So you built a runtime that allow you to do in. In smalltalk to interpret e.g. programs and run them.

[Kent Beck]

No, the. We had a standard compiler, an optimizing compiler. But because we had, we controlled the operating system, we could build really low level probes to collect performance profiling data. So we could get line level profiles for these Fortran programs running on 16,000 processors and great gobs of data.

[Interviewer (possibly a software engineer or tech journalist)]

That's awesome. Like when you're going from. Not just like you're just going lower level, you know, like building infrastructure that runs programs. But then I want to go back to S unit. So the concept of S unit, the. This concept, you put together a test case, what was it?

[Kent Beck]

The test case, test suite and test result.

[Interviewer (possibly a software engineer or tech journalist)]

This really became sticky because then there was Junit, which you later created with Eric Gamma and there's a whole suite Nunit for. I think that was for. Net, Xunit. Net. All of them took over some of these ideas and a lot of modern unit testing frameworks are built on some of these ideas. Why do you think it was so stupid sticky? And why do you think it wasn't created beforehand?

[Kent Beck]

So beforehand because of this social divide between programmers and testers, there was a lot of incentive for the testers to have their own language. This is my tool, I know how to run it, I'm going to run it. And it was very adversarial at that time too, and kind of patronizing, like you're a programmer, you can't be trusted to test. You know, you'll just say it works fine. I'm going to be the adult supervision, you know, and sometimes, and sometimes the programmers really did act that way. So, you know, hard to, hard to argue with, but I think that encouraged this idea that a testing tool is its own, its own world. The inspired decision to use the same language to test as you're testing it was a natural decision because I was in small talk and you should be able to represent anything in Smalltalk. So, you know, and I was just used to how do I represent this as objects.

[Interviewer (possibly a software engineer or tech journalist)]

Sounds like Smalltalk as a language has been early to a lot of things. I sense a lot of innovation coming from Smalltalk because it was one of the first languages that did have objects, but it was a very simple language so you needed to build a lot of things. Which then led to representing a lot of things to talking about them, design patterns and now also, you know, being able to write your test environment if you know, or being forced to do so if you wanted to do it.

[Kent Beck]

Well, there was an ethos that went along with Smalltalk. So if you didn't like the tools, if you're running the debugger and the debugger doesn't have some feature that you really need right now, you just pop on the stack, implement the feature that you want and then get back to whatever it was you were doing that was just a natural thing because there was never this huge gap. You know, imagine today I'm using C compiler and I realized, oh, I wish C had this new feature. We're embarking on a multi year project to go and like huge barrier to entry to go to the next level. And in Smalltalk by design, for example, you pop up menus and they, you can see all of the options right there. That's a deliberate pedagogical choice. It says, okay, well you know about cut and paste, but you don't know the other things that you can do right here. So the menu doesn't just give you cut and paste, it gives you all the things that you can do as a way to encourage you to learn about them. Because eventually you're gonna, I see this format item here and I said, well, what does that do? So it was very much part of the Smalltalk ethos. That this system would teach you as you kept using it. So yeah, it was very natural to build the testing tool in the language. And of course you have to kind of bastardize the language a bit. Here I've got this, this class for some test case and I have a method which is one of the test cases and it starts with test, which is kind of magic, you know, this is getting squidgy. And then when you execute it, you create one of these objects, you send it setup because you don't, you know, may have to build some stuff and then you send it the test t S T something or other and it executes that one thing and then you then assuming, well then regardless, you run the teardown from that. So it's not, it looks like the, the syntax is the same as the language. The, the representation of the tests, you kind of borrow from the representation of just any kind of code and then you interpret it yourself. So it's it, it, it, it's in the language, but it's not really in the language at the same time. But people don't think about that. They just think, I subclass this, I give a method with the annotation of test or with starts with TST and then it just starts working. And that's fine.

[Interviewer (possibly a software engineer or tech journalist)]

I want to jump to a few years later to 1996. You start to work on a project at Chrysler and this is where you met Martin Fowler. What was this project?

[Kent Beck]

I'd actually met Martin Fowler a little bit before that. So as early as the first OOPSLA conferences, the question of how do we manage projects with objects differently than we manage projects with the previous generation of tools? The previous generation of tools definitely gave you many fewer options for change. You'd still have to change code, but it was just a lot harder compared to working with object oriented programs. So what is the methodology we had, we had the structured analysis, structured design. What is the methodology for. For objects and how should it be different? That was the million dollar question at the original 86 Oops law. By the time 94, 95 rolled around, we were starting to get a clue what that would look like. There were, I think the rational and unified process or the, the things that would go into the rational unified process already existed by that time, which was.

[Interviewer (possibly a software engineer or tech journalist)]

Grady Booch was involved in that.

[Kent Beck]

Grady Booch, Ivar James Rumbaugh, Ivar Jacobsen. So people were coming up with some kinds of answers. Ward had come up with his own answer called Episodes written as a pattern language. Because we were like, you know, I don't have a big bag of tricks. I have to keep using them over and over again. And the same is true turns out of of everybody. So you can find that episodes on Ward's C2 site. It's really interesting to compare that because I. I borrowed heavily from that. I borrowed from everything else that I had seen and experienced. But at that point I'd been when did I leave NASCAR 92? So I had been an independent consultant for four years at that point. And there were a couple of workshops held in Snowbird. I don't know why we picked Snowbird, but somebody else did about this methodology question. And I met Martin at the first one of those that I attended and his introduction was. It's just the classic Martin introduction. He said, I am the only person here I've never heard of. And he was already doing some, some great work on analysis patterns at the time, which I knew about. So I was excited to meet him, get to this Chrysler project. The project's important for Y2K, but it's not clear that it's going to be finished in time. Martin was already there as a consultant. I had met Ron Jeffries doing small talky stuff. I don't remember exactly how we met, but long story short, I came in as lead consultant or something, restarting that project in a very different development style. And for that style, I took everything that I knew that was useful and cranked it up to 11 and discarded all the stuff that I couldn't prove we needed. So that was the value system behind this new style of development. Martin and I would visit there periodically. Ron was there full time. I was originally brought in as a performance consultant because I knew a lot about smalltalk performance. And they were using a database called Gemstone, which it was small talk objects, Smalltalk semantics, but coupled with persistence, transactions, indexes, all that database, good stuff. But it wasn't going fast enough. So I said, well, where's the test case that makes sure that I don't break something if I make some changes? And they said, well, actually it's not computing the right answers yet. And I said, well, then I can make it go really fast. And they didn't like that answer very much anyway. Most change I've ever seen over the course of one week, at the end of which everybody was exhausted. They'd been working very long hours. I said, send everybody away for two weeks, tell them to get some rest, we'll come back, we'll throw away all the code that we've written so far and we'll Restart. And we restarted on this three week cadence. Every three weeks we would have more test cases specified by Marie. The payroll expert would be working. And then we'd start another three week segment and another and another. Another. Now it turns out those 11s that we turned everything to, there were several notches beyond that, but it was just. That was the most intensely we could imagine. Replanning, integration, deployment, refactoring and so on. The ideas that went into that was this synthesis of all these experiences that I'd had.

[Interviewer (possibly a software engineer or tech journalist)]

And then this was from. From Ward, when the two of you started to pair and pass the keyboard and. And decide on all the different things that you're going to do. Your experience with tests, as a concept of that, it doesn't need to be the testing team that does it themselves, but you can do it yourself in your own language, which was just new, new. And so all of these ideas just all came together.

[Kent Beck]

Yeah.

[Interviewer (possibly a software engineer or tech journalist)]

And then when did you give it a name?

[Kent Beck]

It started going well at first I was like. I was excited, I was scared. I was excited. Then it started going really well.

[Interviewer (possibly a software engineer or tech journalist)]

So like the project started to go visibly well. Yeah.

[Kent Beck]

After my like six weeks. And then I was happy to be telling my friends about it. This new style of working that we're doing here at Chrysler, this new style of working we're doing here at Chrysler, this new style. They got kind of old to say that over and over again. So now I'm back with the Sasaurus, trying to figure out what are the words. I thought we were really onto something that was going to be big, so I wanted to protect it. Apologies to Grady, who's a good friend now, but I didn't want Grady Booch to ever say that he was doing this thing. So I had to pick. I had to pick a moniker that was unattractive enough that somebody would try and steal it. And this is about the point at which. Extreme sports.

[Interviewer (possibly a software engineer or tech journalist)]

You're now this punk again.

[Kent Beck]

Yeah, well, yeah, I still am, but I'm just an older punk now. Yeah, yeah, but, but a little bit of thumb, the nose at the establishment. Extreme sports were there. I kind of like the analogy with extreme sports because you don't just hop on a snowboard at the top of some avalanche and the first time, no, you have to be supremely prepared. You have to have done all of your research. And then if you have these outstanding skills, then you accomplish things and training and all that. Right. That seem impossible and are impossible if you haven't done all the prep. So it's accurate it's edgy. It's the.

[Interviewer (possibly a software engineer or tech journalist)]

That word extreme, and hence extreme programming was. Was born.

[Kent Beck]

That's. So that's the extreme part. Extreme we had. I knew that a bunch of people wouldn't like it, but that's okay. I started out calling it development, which I still kind of like, because there's more to delivering value with software than programming. But the methodologies extant at that time treated programming as this clerical task. We'll draw these diagrams and these diagrams and build this thing and the 14 ways to visualize this, and then there's some programming, and then we'll draw some more diagrams. And I thought programming sitting, fingers on keyboard, staring at code. That's. That's where I do my learning. Because that's where you can no longer fool yourself that you actually understand. Either you compute the correct value or you don't compute the correct value. So I wanted to elevate that moment of reality meets program. And that's where the programming comes from. Now, from very early days, I also called it XP as a way of separating from the downsides of both of those words, extreme and programming. So we can just call it XP and it's more of a generic thing. Not long after that, Microsoft releases Windows xp. And there's an alternate universe in which I sued them and succeeded. And there's another alternate universe in which I sued them and failed and bankrupted myself and my children all starved to death. So.

[Interviewer (possibly a software engineer or tech journalist)]

Right, right. Because this was right around the year late 90s, and XP came out. Yes, soon after, I think 2000 or 2001, something like that. When did XP extreme programming Hyrule call start to become big? Was it as you gave it a name and you started telling people? Or then there was your book, which came out in the year 2000.

[Kent Beck]

I remember the first talk about XP I gave. I had some flyers to hand out, so I think it was at an oopslab on a panel or something like that. I talked some about xp and afterwards people were give me a copy. No, no. The reaction to it was just tugging on my shirt, wanting a piece of this thing. And I think the XP had exquisite timing in that the dot com. The upside, not the bomb, but the upside of it was just starting to hit. They looked at other methodologies that would say, you know, very carefully prepare, do this analysis document, do this design document. Then a bunch of coding, then a bunch of testing. They could tell that's never gonna work in a world that's changing as fast as the Internet waves starting to crest, starting to Come into, you know, this super hyper growth. On the other hand, we know that this cowboy style of just, you know, you have the Jolt Cola, Rest in peace. Jolt Cola cowboy. You have a bunch of programmers, they do incomprehensible stuff. They don't talk to anybody. You just slide pizza under the door and then you get the code out. That's not gonna work either. Here's this thing that looks like it's kind of in between the two. There's discipline to it, there's iteration to it, there's transparency to it. You have ways of steering what goes on. You have ways of tuning the process. You have all these tests to make sure that stuff actually works. You have frequent alignment between people, whether it's business people and technology people or technology people with each other. Okay, I can see how this could work. And so they could see the Internet is exploding. And I can use XP to take advantage of that opportunity in a way that I. I can't. I don't. There wasn't really another alternative to it.

[Interviewer (possibly a software engineer or tech journalist)]

Basically, XP was giving you a way to move pretty fast and nimble, but also have a sense of stability, not just going wild wobbles. You had tests there, you had the iterations, the planning, the learning. And then when did TDD come along? Because there was a book that you, you wrote that came out, I think, two years later. Test driven development by example. And how did it relate to xp?

[Kent Beck]

So TDD was an earlier test driven development. Test driven development was an earlier rediscovery for me. Remember I was a kid, I read all these books. I remember one of the books my dad brought home and I still haven't found a copy of it, said, here's how you program. This was back in the days of tape to tape. So you'd have an input tape, you know, like time cards, and then you put it through the payroll program, which would write an output tape which was like dollars for checks, dollars for withholding, et cetera, et cetera.

[Interviewer (possibly a software engineer or tech journalist)]

Yeah.

[Kent Beck]

So it was always.

[Interviewer (possibly a software engineer or tech journalist)]

And then really back in the day.

[Kent Beck]

Really back in the day. And. And you'd have these long strings of this. And it's actually functional programming because you can't change the input tape. But operating payroll or operating accounts payable or operating inventory was a process of, I take these tapes, I feed them into this program, I take the output of that, feed them into this program, and blah, blah, blah, blah, blah, blah, blah. And then you really manual, like actually physically pulling a tape off and moving it over. Yeah. And it's. So it Said, here's how you write one of these programs is you take an input tape, an actual input tape that you need to process, and you manually type in the output tape. You expect that to generate. You say, okay, well this number of hours, should I, I should have a record in the output that. Like this.

[Interviewer (possibly a software engineer or tech journalist)]

So I see where we're going with this. You're, you're defining the, the output you're

[Kent Beck]

before you start on the program.

[Interviewer (possibly a software engineer or tech journalist)]

Yeah. So first you need to know, what do I expect? How can I validate it? Correct.

[Kent Beck]

I had read that as a kid, didn't understand diddly squat. But, but it's, it's back in the, back here someplace. I wrote S unit for the first, started using it, gave it to Hal Hildebrand, one of the smartest programmers I knew. I didn't figure he would need it. He used it, he loved it. So I knew I was onto something with, with this, this testing framework. And then I was just kind of farting around and remembered this typing in the output tape first and mapped that onto the testing that I was doing with S Unit. I went, well, if I followed that pattern, I would write the test before I wrote the code. And I can remember laughing out loud because it was such a stupid idea. Why would you write a test that you know is going to fail? You don't even have the classes defined yet. You don't have the methods defined yet. It's just, it's going to fail a bunch of different ways before it could possibly succeed. Cool. Let's try it and see what happens. So I, I used Stack as my first example. So I have a stack new and I push something and I pop it. I should get the same thing back. Okay. And then I went to program it and okay, well that's easy to satisfy that. What's the next one? Well, you push two things and you get them back in the right order. Okay, and this. And dupe pop top is empty. I'm finished. Where's the anxiety? Oh, just gone.

[Interviewer (possibly a software engineer or tech journalist)]

Oh, for the first time.

[Kent Beck]

Wow. I can't imagine another test case that wouldn't pass. So I'm really, I'm finished and I feel great. I feel finished and I am finished. Wow.

[Interviewer (possibly a software engineer or tech journalist)]

Going from this is a stupid idea, let's try it.

[Kent Beck]

Absolutely no meta comment. Always try your stupid ideas if you can do it cheaply and reversibly. Jumping off a bridge is not a reversible decision. Not talking about that. I'm talking about stuff like this where you're just like, here's a stupid idea, 99 times out of a hundred it'll fail. But that one time you won't have any competition because nobody else is stupid enough to try this idea. Part of this punk attitude. I don't care what you think about this has enabled me to just try lots and lots of stupid ideas. And most of them you don't see. But there had been a string of them which worked out way better than they would have expected to work out well.

[Interviewer (possibly a software engineer or tech journalist)]

And then a bunch of other people tried these ideas as well. You know, like, I think TDD is a good example where there was a time where shortly after you wrote the book about it as well, it was, it was a super popular book. I still remember. I think I had a copy as well. Back in the late 2000s, people were like doing, you know, group exercises. Developers were developing accordingly. Over time, it probably dropped, I would say in the 2010s, I saw fewer and fewer people doing it and it almost went out of style completely. And now with, with agents, the idea is back because turns out it might take more time. What thought. But agent. Agents can do that. But it's a. It's pretty useful for them to test themselves.

[Kent Beck]

It costs tokens in the short run, but it can save them in the long run because one of the classic genie mistakes is stuff doesn't work. So how do you, how do you pull in the reins a little bit? And why did TDD go out of fashion? I think there's a big part of it is I work on something for a while and then I switch to something else. That was true of patterns, it was true of J in it. It's true of tdd. It's true of xp. I just move on to the next thing. So I moved on to the next thing. TDD is out there. And then there were people who used it as a moral cudgel, like you should be. If you're not using tdd, you're not professional. And that's just such bullshit. People can write very good software with a wide variety of workflows. Now, there's advantages and disadvantages to different workflows. The sweet spot of TDD is this combination of discovery and realization. I kind of know where I want to go. I don't know exactly how I'm going to get there, but I do know the first step. So I take the first step and that teaches me something, which lets me take the next step and that teaches me something. If you can just go implement, implement, implement, implement. Fine. There's other workflows that are fine. If you just want to sit there and go learn, learn, learn, learn, learn, learn, learn. I don't think that works very well. But you certainly don't need tdd. It's when you have this rapid alternation between I do a thing, I learn a thing, I do a thing, I learn a thing, I do a thing, I learn a thing. That's where TDD is really powerful. But it's not a moral decision, it's a practical decision.

[Podcast Host]

Tensorbound development is one of Kent's most lasting contributions to how software is written and shipped. And today with agentic development, it's more important than ever. If you work with agents, your job is no longer writing code, it's specifying and testing it. This is where I need to mention our presenting sponsor, Antithesis. Antithesis is the most effective method of verifying a genteel code today. Let me explain how it works. Antistasis runs your whole system in a hostile simulation. By doing so, it finds every bug before your users do. And because the simulation is fully deterministic, Antistasysis doesn't only find bugs, it gives you a perfect reproduction of every issue. I know this sounds closer to science fiction, but it's actually hardcore engineering under the hood. Jane Street Fly IO and the ETCD community ship agent written code with full confidence because they know it's been verified by intesthesis. To see more case studies and details, head to antistesis.compragmatic that's intesthesis.compragmatic Kent has spent his career building the primitives that the rest of us now take for granted. Unit testing design patterns, refactoring and building on solid primitives is exactly what our seasonal sponsor WorkOS is all about. If you're building any SaaS, especially an AI product, sooner rather than later, you'll need to get around building enterprise features. But things like AUTH for apps and agents. WorkOS handles it SSO SCIM fine grade authorization built for how agents actually operate the fastest growing AI companies Entropic OpenAI cursor Perplexity already trust WorkOS to solve these problems. Check out workos.com and with this, let's get back to Kent and where the Agile Manifesto came from.

[Interviewer (possibly a software engineer or tech journalist)]

I want to talk about the one thing that you're also very known for, the thing that 17 people wrote, but you're the first one listed the Agile Manifesto. Can you take me back to what happened in Snowbird? What was the industry like and what made all of you come together?

[Kent Beck]

There were a bunch of people Remember we were talking about what is the methodology for objects? And you had kind of this dominant rational, unified process, which I say is neither rational nor unified nor process, but it's a separate. Mostly I did that to tweak people's noses, but that was the adult way to, to do development. And there were a bunch of us who, if you talk to Grady, if you talk to Jim and you talk to Ivar, how they would apply it is actually looks a lot like the way that I would develop. But doesn't matter what you would do. What matters is what the people who read the stuff that you write would do. And it was being used in a very waterfall style, bunch of analysis, bunch of design, bunch of implementation, separate testing, disaster, over and over and over again. So a bunch of us looked at that and in our own ways, in our own sequence of time, said, no, we, we shouldn't do this, we should do something else. And we started making enough noise that we started getting attacked by the rational, unified process people. Well, you don't want to do that. You want to do my thing and here I'll sell you tool for millions of dollars to help you do it. I, I can understand why they would attack. But we started realizing, okay, if we're all going in this similar kind of directions, Scrum feature driven development, we had to come together. We had a meeting in Norway where we got together, gave a presentation. This is towards the end of the time I was living in Europe, I lived in Switzerland for two years, 97 and 99. So in 99 we, we flew up to the tip of Norway and took the Hurdigruten ferry, which I practiced saying and I'm sure I still butchered it. Took this ferry down to Bergen and it was light all day or all night. Bucket list item. Definitely take this if you ever get a chance, because the scenery is just absolutely spectacular. But we were meeting and talking about, do we have enough in common that we could actually do stuff together. The sense of that meeting was, yes, we should do something together, but there's still a lot of friction and there's a lot of divergence. You're talking about people with some healthy egos, strong opinions, me not the smallest among them. So when we got back, Jim Highsmith and Alistair Coburn convened another meeting at Snowbird, same place that we'd been having these kind of methodology kind of meetings for a while. And so we all went there and other people have told the details of the meeting. I'm not going to be able to recall them precisely Enough. So find one of those recountings of this. But it was not going well for me personally. I had a nasty sinus infection and I was on some heavy duty drugs. So I don't really remember much of the meeting in general, but I knew that things weren't going very well because there's all these people and they. I want my stuff in. No, I want my stuff in. And that contradicts your stuff. So we all, we took a break. We walked out and Martin and Jim Highsmith stayed behind. When we came in from the break, there was the basics of the manifesto. You know, that format. We value these things, but we value these things more. And the four specific items that was, that was all in place. And then the. And that was just a magic moment that I had nothing to do with. And then we came up with the principles. And I remember the. The only word in there that's mine is the word daily. When it talks about daily interaction with users. I don't think I had another thing in there. But when it came time to publish it, what order the names go like they're alphabetical, wasn't it? Absolutely alphabetical. So, so when, when people say, oh, you're a signatory, I say, no, I'm the first signatory. Alphabetically.

[Interviewer (possibly a software engineer or tech journalist)]

And then what was the impact of the Agile Manifesto?

[Kent Beck]

Instant, instant. People were so excited again. Were now the rumblings of the.bomb.com, it was still going up, I think.

[Interviewer (possibly a software engineer or tech journalist)]

So it was towards the end, but

[Kent Beck]

definitely towards the end, like, but people were still looking for a. Like, how do we do this? How do we do this stuff?

[Interviewer (possibly a software engineer or tech journalist)]

How do we build software quickly, cheap, reliably. Everyone's searching for that.

[Kent Beck]

With optionality.

[Interviewer (possibly a software engineer or tech journalist)]

With optionality, yeah.

[Kent Beck]

Because when things are uncertain is exactly when options give you the most value. And we had a story about how you could preserve optionality. All of us in. In our own separate ways. That was another case. So XP was the first time I had people tugging on my shirt. Junit was another one, which was S unit. I had S unit. Eric was using. Eric Gamma was using this new language, Java. We were flying to America. He was going to show me Java. I was going to show him S unit. So we developed Junit testing itself in itself on the flight from Vienna to Washington Dulles. Wow. And when we landed on the plane, no Internet. No Internet. Two and a half hours of battery, like the clock is ticking. Yeah. No power adapter in the seat. Oh, it was, it was like horse driven computing. So we landed and we gave J Unit To Fowler, who was at that oopsla. And the next day, I hear you, you have a Java testing framework. Can I get a copy? So we made floppy disks, three and a half inch diskettes and we were handing em out as fast as we could because there was so much demand for it. So that was the second time I've been through that kind of a demand.

[Interviewer (possibly a software engineer or tech journalist)]

Product market fit, quality.

[Kent Beck]

Yeah, yeah, exactly. Product market fit. And then Agile Manifesto was the next version of that where people were just really excited about it. Beautiful piece of marketing to have the original signatories and then if you wanted to sign it, you could sign it

[Interviewer (possibly a software engineer or tech journalist)]

for a while, I think close it after a while because they got too many people right.

[Kent Beck]

But that meant that people felt invested, they were already bought in, they'd already attached their names to this thing.

[Interviewer (possibly a software engineer or tech journalist)]

Is it interesting, right, how being invested, being able to contribute or feel you're contributing it, it can make a difference. It has made a difference and for Agile for sure.

[Kent Beck]

So one piece of follow up. Is that word agile part of the argument? Yeah, argument was around what are we going to call this thing? And somebody suggested Agile. I don't remember who, but probably somebody. Somebody does and I objected. And what I don't like about it, didn't like about it then, and still don't like about it, is it's not defensible. Nobody's going to say I'm not agile. Oh no, I prefer rigid development. Oh, I prefer inflexible development. No, everybody's going to say that they're agile. Which extreme doesn't have that problem. If you work hard at your skills at being able to pair and being able to design incrementally and being able to test thoroughly and, and build tools and you make that investment. Now you say okay, I'm an extreme programmer. If you haven't made that investment, you're never going to say that you're an extreme programmer if you're not. But you're gonna say you're agile even if you're definitely not. So that was my objection back then and that certainly played out. That word not only doesn't mean anything anymore, it means something negative.

[Interviewer (possibly a software engineer or tech journalist)]

Can we talk about that of the afterlife of Agile and some of the capital a version. There's a whole industry that was growing bad initially was meant to do good things, but it turned into a snake oil industry in many ways. We now have scaled agile frameworks that are sold for massive amounts for huge companies which you know, bogged in that. With even more bureaucracy you can imagine how did you see this being played out and did you expect Agile to grow this big into both a commercial story and then all of these, I guess, snake oily parts?

[Kent Beck]

I was certainly afraid that that was going to happen at the time that we put it together. The Agile Manifesto is the intersection of the ideas of the people in the room. I think there's a lot more to software development than is contained in the manifesto. And I've written books and books and books about what I think those things are. Without the foundation of technical skills, you can have the, the best intentions of we're going to be able to replan and we're going to be able to implement in any or, you know, we have a set of features and we can implement them in any order and we can add new features anytime we want. And above, you can say you're going to do that. But if you don't have the technical chops to write efficiently, write reliable software in bits and pieces, to design in bits and pieces, to preserve and enhance, optionality to write your own tools when you need to do that. Those are. Things are technically difficult. It's like putting somebody at the top of the avalanche on a snowboard for the first time. Well, there's a certain kind of agility as you fall down the mountain and break your body into multiple parts. But this is not really what we're talking about. You need that foundation. And there were people who were willing to say, no, no, no, don't worry about that. This is easy, you can do this. Anybody can do this twice the work in half the time. From my perspective, that's just a lie. Can you get twice the work done in half the time? Yes, absolutely. Is it going to be a lot of hard work gaining the skills which aren't taught in computer science school, aren't frequently modeled in your first employer. You're going to have to work hard to gain the skills to be able to do twice the work in half the time. In the, the genie world is just playing this out again. Well, everybody can be a programmer.

[Podcast Host]

Yeah.

[Kent Beck]

But everybody can't be the same programmer. Yeah.

[Interviewer (possibly a software engineer or tech journalist)]

Seems like there's a pattern where when there is a new technology or a new methodology in this case, but I guess it's intergenerational technology. Yeah. A technology that a group of people, a group of highly trained people can get really good results with it and then they publish it and they share. This is working for us. Here's the results. There's a bigger industry going around that saying what you just said, that anyone can get these results and we will sell it to you, we'll show it to you. And of course by the time you realize, for example, a company like a large bank realizes that it's not really working, they're heavily invested and maybe they're actually getting some minor results, just not the same. And then I guess you can argue of like this is. This is the whole point of snake oil, right? Like snake oil, it does something, just not what it was advertised. Let's talk about what happened after 2001. So there was a big.com bust. Can you take us back to what it was like being in the middle? You were in, were you in Silicon valley at that point?

[Kent Beck]

87 to 97 we lived in the Santa Cruz mountains above Silicon Valley much of that time I commuted to work. Then we moved to Switzerland 97 to 99. Then in the last part of when we were living in, in Boulder Creek in the Santa Cruz mountains, we had bought acreage near my grandmother in southern Oregon. So we bought eight hectares of just trees and started developing power. Well, road and so on. Went to Switzerland. Oh, we built the office and we had a trailer and then we went to Switzerland and we came back. So I was living in rural southern Oregon at that time and the industry

[Interviewer (possibly a software engineer or tech journalist)]

just went through this massive boom which there are similarities as I'm talking with people with the current boom whenever you're working in AI right now. And then there was a sudden bust that again, I've learned it from his history books or like reading back news, but apparently it was sudden, it was shocking. How did you see it? What happened in the industry? What, what, what were your friends working as programmers observe or how were they impacted?

[Kent Beck]

It was horrible. For me personally, the turning point was 9 11. I had eight months booked solid work at very high rates, higher rates than I can charge now even with inflation. And the day after 911 everyone canceled. I was also finishing the house that we were building. So we were, we were about to come up on some big bills to finish the house at the same time that all of my income disappeared.

[Interviewer (possibly a software engineer or tech journalist)]

It's overnight.

[Kent Beck]

Overnight.

[Interviewer (possibly a software engineer or tech journalist)]

Wow.

[Kent Beck]

So things had already been bad. There were, there were big bankruptcies and the pets.com and the whatever that, that was already happening. And then 911 just shut down everything. That was a big shock for me and I ended up burning out pretty thoroughly. Severe depression. I had a really important lesson to learn about boundaries. So up until that time, remember periodically I had people tugging on my shirt and yeah, you are a three really

[Interviewer (possibly a software engineer or tech journalist)]

big pot of market Fits where people are after you.

[Kent Beck]

Patterns. Even before that was also like that.

[Interviewer (possibly a software engineer or tech journalist)]

But you were a star.

[Kent Beck]

I was, Yeah. I was feeling. Yeah. And I would get these messages. Somebody would say, oh, Junit saved my life. XP was fantastic and I love it and you're a genius and blah, blah, blah. And I'd feel really good. I didn't get a message like that. Then I started getting messages. XP ruined my life. I lost my job, my wife left me, I can't see my kids. I'm living on the streets. You. And then I would feel really bad. And the way I think about it now is there's the way people perceive you and there's the way you perceive yourself. And then there's what's really true, which is somewhere different than either of those. When people are giving you a bunch of feedback that you're more awesome than you think you are, that just stretches your head. So you see this in celebrities periodically there'll be somebody super famous and then their head explodes. And that's that gap between how people see you and how you see yourself. And what I had to learn was the reason that people come to me with those out of proportion responses is because that's what they need. They need a hero or they need a villain. And their need for a hero or a villain has nothing to do with me. If it wasn't me, they'd be contacting you, they'd be contacting somebody else. It really doesn't have anything to do about me. But that recalibration where I'm like, I'm trying to convince myself that I really am this awesome. No, I get feedback that I'm not. That was a serious reset for me. So I went through a bunch of mental health problems. Couldn't work, couldn't. Couldn't program at all. I started over with Sudoku and eventually I could do Sudoku's on Easy, and then eventually I could do them on medium. And then I started on on crossword puzzles.

[Interviewer (possibly a software engineer or tech journalist)]

Wow.

[Kent Beck]

And then eventually I got to a programming problem. I was doing a bunch of stuff with Eclipse when it was new. I got to a programming problem and I nailed it. And I went, oh, this is still fun. I can still do this. But yeah, the kind of a lost decade from 2000 to, let's say to 2011 when I joined Facebook.

[Interviewer (possibly a software engineer or tech journalist)]

So you really went from being on close to the peak of the industry or the professional mountain, if you will, to just, I guess, just finding your way. Do you think something similar might have happened? Was it not for this sudden crash or being a dust. The sudden. Or was it just the intensity of everything just being pulled out of under your feet? What do you think it was?

[Kent Beck]

I think that people are coming to me with these expectations that I know I can't meet that was. It's going to blow up somehow, eventually, for sure. You can't just live the rest of your life like that. And that's what the classic midlife crisis is, is the masks that used to work, that felt like they used to work. You realize, oh, they're not gonna work going forward. I have to be myself. And actually, they've never worked. I was just fooling myself that they had worked. Yeah, I think that's. It's gonna come. It's at 35 or 40 or 45, and mine was at 42.

[Interviewer (possibly a software engineer or tech journalist)]

But then you. In 2011, you got into Facebook, and I'm really intrigued by this story because at this time, Facebook was 7 years old, which meant that the median age was probably like 24 at the company. And there you are, an industry legend again. You've had all these contributions, tdd, xp, knowing how to build efficient software, and Facebook is building efficient software in a different way. And now you're showing up when you were 50 with these people half your age. I assume you could have gone back to consulting and do what you've done before.

[Kent Beck]

I was trying to do the same thing, so I needed the money for sure. Trying to do the same things as a consultant that I'd done before and just there was no, zero interest out there. I had college to pay for. I have five kids and I knew I was going to have two tuitions for four years in a row. I needed some stability in income. Problem with book publishing. Doesn't make much money. Yeah. Except in rare cases for a guy.

[Interviewer (possibly a software engineer or tech journalist)]

Well, in the rare cases in my case, where Amazon self publishing has been invented.

[Kent Beck]

Yeah.

[Interviewer (possibly a software engineer or tech journalist)]

And people buy your books in bulk. But outside of that, even for. Yeah, it doesn't.

[Kent Beck]

Yeah. I love teasing you because you're so successful. I know that even if you can't take it, you have to take it.

[Interviewer (possibly a software engineer or tech journalist)]

I am here and now here on this podcast.

[Kent Beck]

So I needed some stability, number one. But number two, these people were doing nothing that was in my books and they were running a stable site. Not perfect, but at this crazy scale, it was stable and kind of unprecedented. They were expanding users and growth was expanding dramatically, and they were innovating all at the same time. So how in the world are these like. This is a bumblebee. It can't Fly according to my theories. I want to find out what's going on in there. So at that point I'm still very curious about methodology and how people get along and software development sort of in the societal scale. But I also needed the money. So I joined and I think I was the first, were one of the first remote engineers. There were about 2,000 employees, total 700 engineers at that time. And I just wanted to parse how does it work that they have scale, growth and innovation at the same time. Because I'd never seen anybody do all three. You'd see people do one of those two was rare. In all three, I was unprecedented and

[Interviewer (possibly a software engineer or tech journalist)]

apparently they weren't too interested in no

[Kent Beck]

in the prior art.

[Interviewer (possibly a software engineer or tech journalist)]

Can, can you tell that story about your TDD class? I think you told it like many, many years ago somewhere else.

[Kent Beck]

Yeah, absolutely. So I get there and I'm nervous like, you know, how am I going to contribute? I don't want to just, you know, be here for a week and then get kicked out. So there was going to be a hackathon and hackathons often came with classes. And so there was a, a signup sheet for classes. And I thought, all right, I'll, I'll give a TDD class. Cause after all, you know, you wrote

[Interviewer (possibly a software engineer or tech journalist)]

the book, I wrote the book, I

[Kent Beck]

invent, you know, blah blah, blah, blah, blah. And they clearly need it. I could see, because nobody's doing it. Very few unit tests at that time, which just shocked me. How can this be? So I said, I put on the signup sheet TDD class for me from the Kent back just before my class was one on Argentinian Tango. And just after my class was, was one on advanced Excel techniques. When the time came for the classes, the Argentinian tango class was full, the advanced Excel class was full. And no one, not one, not even like a pity sign up. Zero people had signed up for my TDD class. So these engineers clearly felt like they had it already dialed in and they didn't need anything from this old guy. So I decided, you know what, I'm just going to forget everything that I think I know about software engineering and I'm going to try to do things I'm just sort of monkey see, monkey do. I'm going to copy what I see people doing and get feedback and see if I can learn to develop in this different style as quick, quickly enough. Can I relearn software engineering fast enough not to get fired? And I ended up staying there for seven years. And what did you learn?

[Interviewer (possibly a software engineer or tech journalist)]

What made it Work because again, again, going back there, what Facebook did from the outside would have made no sense. They didn't have tests at the time they were running this Basif site, somehow keeping it working. Oh, and they had young engineers who didn't have a decade or two of experience to know what mistakes to avoid.

[Kent Beck]

Mostly young engineers.

[Interviewer (possibly a software engineer or tech journalist)]

Mostly.

[Kent Beck]

So they. We had. We had some very senior people with great leadership skills who could model it. Many layers of feedback were built into the system. So we had developer machines that ran the site. So if you wanted to change the color from blue to green, you could do it on your developer machine.

[Interviewer (possibly a software engineer or tech journalist)]

You could check out. There was a mono repo ish thing.

[Kent Beck]

Yeah. And so you could just change anything and see the. Because it was php, you could see the results of that change in seconds. So that gave you one level of feedback. Then you had code review, which gave you another level of feedback. You could roll out internally more frequently. And everybody was using Facebook for all kinds of stuff, personal and internal business stuff. So whatever feature you developed, people would start using it immediately. So you'd get another round of feedback. Then we had this phased rollout process where you'd start rolling your stuff out if there was a problem. The blast radius would be limited to a few million people.

[Interviewer (possibly a software engineer or tech journalist)]

Not like automatic rollback based on signals.

[Kent Beck]

Yeah, not the whole thing. Chuck Rossi's deployment team also was another level of feedback. You had stars. They would secretly give you a number of stars, and if you were three stars, they wouldn't look at your stuff. But if you were a one star, you just couldn't get your stuff pushed. So that was another round of feedback. Then you deploy stuff and you'd look at the results, like the observability, early observability stuff. So you get more feedback about what you're doing. So feedback comes in layers, like a filter. And if you get enough different layers, Swiss cheese, it's. The bad stuff sticks and the good stuff still goes through. Yeah.

[Interviewer (possibly a software engineer or tech journalist)]

So the Swiss cheese model, even though

[Kent Beck]

there's holes everywhere, as long as they don't line up for six layers of cheese, then. Then you're good. And unit tests, would unit tests have been better? Maybe. I wrote unit test for the first feature I rolled out and I still caused a site event because there was some other coupled code that I didn't find.

[Interviewer (possibly a software engineer or tech journalist)]

Meaning and knowledge.

[Kent Beck]

Yeah. Yeah. Not a bad enough one to. To go through a incident review, which is another. Another layer of that where every Friday the most senior people would get together and anybody who'd caused an incident Would come in and explain, here's the timeline of what happened, here's what we learned, here's what we need to do to avoid this ever happening again. And if you went into incident review and you explained it that way, you were fine. If you went into incident review and said, well, ops did this and somebody else did that and blah, blah, blah, blah, you could literally get walked to the door. That was another level of feedback that made sure that the same mistakes didn't happen again. And that was taken seriously.

[Interviewer (possibly a software engineer or tech journalist)]

What I know and what many people know as well, Facebook, for a long time, they did not do unit tests for most things. In fact, I think if someone tried to push, they would often just delete it in code review. And, you know, that sounds bad in itself, especially at a time. This was the early 2010s where testing was considered really best practice or baseline. But I think what people missed is all these other layers that most places did not have. My understanding is that to this date, Facebook, the website and mobile apps rollout infrastructure, is probably the most advanced in the world in how it automatically collects signals and it does the auto rollout and the auto rollbacks, which just does not exist in 99, 9.9% of places because they don't have their scale or their opportunities or even their business. Right. Because I guess, you know, outages are just. It's a bit different when a utility company goes down versus when Facebook might go down. The impact, yes.

[Kent Beck]

And while I was there. So by the time I left 2017, Facebook is a very different place than when I joined. Over the first couple of years, Facebook became much more like a utility. The big site events, the big negative incidents. We, the notable ones would get names. And so there was one called the call the cops sev. And it was the first time that people called 911 when Facebook went down.

[Interviewer (possibly a software engineer or tech journalist)]

Wow.

[Kent Beck]

It was like, oh, crap. We. We need to take this even more seriously than we've been taking it. Okay. Because we're social infrastructure and people just expect it to absolutely work.

[Interviewer (possibly a software engineer or tech journalist)]

And what was it like inside Facebook, how the engineering culture, how engineers work compared to the rest of the industry? Because now you. You were now in this bubble, which worked very differently.

[Kent Beck]

There was very little planning. There were no deadlines as such. Zuck would say, I want to increase the. The resolution of photos, you know, by a factor of four. And the engineers would say, well, we can't do that, because blah, blah, blah. But he'd say, yeah, I understand. Still want to see the photos looking better. And then people would go and do it and it would take as long as it would take, or you'd work on it for a while and if it just couldn't for whatever reason, then you'd switch to something else. Early on, I had lunch with somebody who'd come from Microsoft and said the thing about Facebook is if you're at Microsoft and you have a good problem to solve, you will defend that problem tooth and nail because there aren't enough problems to go around. And at Facebook, if you're solving a problem and somebody else starts solving it, you just go on to the next thing because there's always some other trash fire burning someplace else. And that's, that's certainly no longer true at Facebook. It's opportunity starved. Then it was opportunity rich. I accidentally saved $5 million a year during my boot camp.

[Interviewer (possibly a software engineer or tech journalist)]

No way.

[Kent Beck]

I was looking at the Photos code, which at that time was a single PHP file that I printed it out and taped it all together. It was 18 pages. That was Photos and it was the biggest Photos site in the world at the time. And I looked at it and I thought, man, there's just, there's something wrong here. We were very careful to reduce the number of round trips between the front end code and the cache or even worse databases. And so I looked at it and I thought there's some. I realized, oh yeah, they, this can be made more parallel. So I made that switch and a week later the photos manager came to me and said, ops noticed that the demand on the Photos machines suddenly dropped when we rolled your stuff out. And they, they can recommission enough servers to save $5 million a year. And I was just farting around, you know, so there was like the, the gold rush and there's just gold nuggets sitting on the ground and you just pick them up. That's not true today. And even by the time that I left, it was, it was no longer true in that same kind of sense. But you could just be a programmer and do programmer stuff and you had enormous leverage, which was part of the magic of it at that time. This is pre ipo, the middle management, Middle engineering management, like first and second level of engineering management all had generational wealth in vested options, but had to go public. So that tier was very focused on global optimization, not local optimization optimization. They would give up. You know, you, you talk to some team, they're like, well, we could really use you, but I think you really should go here because that's what's going to make my stock options go up. The most, which is crazy behavior. Once you get into this scarcity desert kind of mindset, like nobody's going to act that way. But at that point that was, it was extremely novel. I collected a whole series of this. I found this manuscript the other day, how Facebook works. There were a bunch of policies that I'd never seen before, one of which was 50, 50 goals. So six month performance review cycle. At the beginning of six months you'd say here, here are the thing, here are my goals. And when you reviewed those with your manager, if you had accomplished half of the goals, you get a plus. If you accomplished everything you set out to accomplish, people you know, you're sandbagging, you're not trying hard enough, you're not risking enough, you didn't learn anything over the course of the six months. If you accomplished none of your goals, you were just out. So engineers and engineering managers would get fired at them much sooner than I'd ever seen anywhere before, which creates anxiety. But it also like you knew you didn't have to protect yourself from slackers because everybody else was under the same kind of pressure and you were all trying to work make the world more open and connected. Now it turns out the world can be too open and connected, but that's a separate setting.

[Interviewer (possibly a software engineer or tech journalist)]

Yeah, but it feels like you were there during the golden years. Now it's morale is terrible with all the engineers are being assigned without asking them to do data labeling. It's all turning into very different culture. But I guess it just shows that places do change. But it seemed that was a time where Facebook was growing. The mission was very interesting. There were, as you said, more, it was opportunity rich and you were coaching people, coaching engineers there. What did you learn about folks who are already, I guess pretty standout? If they got into Facebook, how in what ways could you help them? Or did you help them?

[Kent Beck]

So about a year in, I've been working on a C project infrastructure for the Facebook messenger product which had come out, become very successful, kind of out outgrown its infrastructure, needed support and I was not a good C programmer. And so I was not going to stand out there. I had six months to turn stuff around. And in that, the missing years, I kept body and soul together by doing coaching, remote coaching. And so I, I knew I'd had, I don't know, hundreds of hours, maybe thousands of hours of, of coaching interaction. And one of my friends at Facebook, old timer named Peter Demov, said, you've talked about this coaching stuff, why don't you just start doing that and Facebook was very much a, you're an engineer, you feel like doing a thing, you do the thing. If it doesn't work out, you take the consequences. If it does work out, you get the rewards. So I thought, all right, I'm a coach now. So I hung out my shingle and I found my first three students and started with daily one hour conversation, which turns out to be way too much for three weeks or four weeks or something. And two of the students worked out well and one of them got fired. But yeah, they told other people. So people would come to me and ask for this coaching thing which evolved into a program called Good to Great. And the idea was I'll talk with programmers who are good but have kind of stalled. You know, there's this punctuated equilibrium that happens where people get better and then they, they gather experiences without growing much and they need a little kick to get em up to the next. And so that's the good to great part. And I was coaching people one on one. I'd coach six people at a time, which is exhausting. But I was also matching up other senior engineers with junior engineers for coaching. And then we would have the meta conversation of coaching. The coaches tell me about something that happened this week that was a you didn't know how to react to or is difficult or we'd all talk. I brought in a storytelling consultant to, to do an off site. I hired Aaron o' Rourke, was my administrator because it's not my strong suit kind of lining stuff up. And she worked with HR to analyze the program and discovered that the people who'd been my students were twice as likely to get promoted in the year following coaching than a cohort that was the same ish but didn't get coaching. So it, it really worked to, to accelerate the career progression of the people. I didn't handle the politics of it very well. So this was, this was learning and development outside of the learning and development organization. And I didn't understand that that was going to be an issue. So by the time I left, there were big fans of Good to Great, but there were also people who didn't like the fact that it was around. So I ended up coaching probably 200 people individually. I would write classes that I would give and then I'd teach other people. Then to give that thousands more of engineers went through it. And just before I left, I went to an off site with the top 1% of Facebook engineers. And out of the hundred plus people, 100ish people there, 10 of them were former students of mine who had gotten promoted to that level. So I felt really good about how that all worked out. That was a kind of back to Ward. That was a kind of interaction that I was able to have with Ward. It wasn't. It wasn't. It's not always pleasant. It's not a pat you on the head and you're going to be fine. It's a. It's a don't like, no, you're screwing this up. Go try this thing. Tell me how that works. You didn't try the thing. Oh, you don't want to work on this? Okay, we're done. Quite uncompromising. I say coaches are there to identify and induce productive discomfort. But the coaching program as a whole, by the time I left, I had great, great, grand students. I'd coached people who became coaches, who coached people who become coaches who now were coaching. I think there's an element to that, a way of learning in that kind of style that just can't be duplicated. So when Dario says we're going to eliminate software engineering, you don't understand what software engineers do. We're going to transform some of the activities that go into software engineering. Absolutely. Ah, I'm having a blast. But the, The. This idea that we're code monkeys, Requirements and Jolt Cola in, code out. Come on.

[Interviewer (possibly a software engineer or tech journalist)]

To be honest, I do sense that Dario has a disdain for developers. Software engineers, should I say? Or. I've never seen an indication that he likes them or that he was one.

[Kent Beck]

No, he clearly wasn't one. This is fine. You can be like a physics background or something like that. That's fine. And you can say, I'm going to replace your job. To me, I don't consider that disrespectful. That. That's ignorant.

[Interviewer (possibly a software engineer or tech journalist)]

By the way. Can we talk about. Now, you. We bring this up every. You brought this up multiple times in our discussions. People awfully want to replace us developers, and we should probably reflect a little bit on that. You've had time to reflect.

[Podcast Host]

Why.

[Interviewer (possibly a software engineer or tech journalist)]

Why does this keep coming back?

[Kent Beck]

Because we're kind of assholes sometimes. I mean, that's the. That is the long and the short of it. My perspective is someone on the spectrum who's been an engineer for a long time, whose dad was an engineer, whose grandfather was a geeked, you know, in his own. In his radio kind of way. So I come by this all honestly. We don't necessarily have good emotional regulation skills, don't have natural empathy. That's why I play poker, by the way. So I get feedback when I don't have good empathy. We oftentimes are more direct than other people can easily handle.

[Interviewer (possibly a software engineer or tech journalist)]

Yeah.

[Kent Beck]

In the business setting, yeah, I'm just telling the truth. Or I was just asking a question. Those are the most hideous things that, that I say because okay, yeah, you were just asking a question, but you're being an asshole asking that question. And you, I didn't realize it, but I was. Because that's how people react. So I don't expect anybody to cut me any slack. There are people who say, well, it's up to the rest of the world to adapt to the ways that I'm weird. It's just not because, I mean, it's not going to happen. So learning empathy, learning how to read body language, learning how to read tone of voice, this is not natural skills, but they're skills, they're learnable. I'll never be as good at them as my partner who's social genius, but I can be not horrible at those kind of skills. Things like belligerent. That's a common social strategy for people like me and has been a social strategy of mine. There's some disagreement between us and the way I resolve it is, you know, how long is this going to take? Four weeks. Has to be done in two weeks. Yeah, that's an invitation to have a conversation. When I say four weeks and you say, no, it has to be two weeks. I don't have to shrink and say, okay, I'll try and get it done. I also don't have to say, yeah, Cody yourself, jackass, that neither of those responses help say, all right, well, let me, let me understand your needs. Not an easy task for me, but I can, I can do it. I have a little checklist in the first Terminator movie where he's got the little pull down menu of responses. Yeah, it feels like that oftentimes. But it's better to have the pull down menu of responses than to do something that alienates the other person and ends the conversation before it's actually finished. I think it's those kinds of things. It behooves us to learn how to communicate in a style that other people can actually listen. Which is why I bring in analogies from the finance world, from, from sports, from history, from every place I can find in a desperate attempt to understand other people and help them to understand my perspective and what that brings to the situation in a way that they can actually comprehend it.

[Interviewer (possibly a software engineer or tech journalist)]

Jumping to the present times where now for a couple of years we've had AI LLMs. But now we just call it AI or as you call the genie. Yeah.

[Kent Beck]

And it grants wishes, but it's not actually what you want.

[Interviewer (possibly a software engineer or tech journalist)]

And it has some interesting characteristics. I'm wondering how do you think this will change? Individual developers work and also teams companies, tech companies that are building software.

[Podcast Host]

What are you seeing so far?

[Interviewer (possibly a software engineer or tech journalist)]

Talked a lot about how what software engineering really is. We talked about the understanding, the communication, the, the learning. As you are coding. It seems that that is definitely shrinking if not being taken away.

[Kent Beck]

That's a choice. But I'll let you finish your question.

[Interviewer (possibly a software engineer or tech journalist)]

Just look, looking across the industry.

[Kent Beck]

Yes.

[Interviewer (possibly a software engineer or tech journalist)]

And it also feels that there's this analogy which what you said when interfaces were out, that people were overdoing the interfaces and it feels it's like this, we have these AI agents or genies as we call and people are using it everywhere and they're going mad and forgetting some of the sensible stuff. Yep.

[Kent Beck]

What an open ended question. So one of the things is that the pace of development is definitely accelerated. One thing I wonder, the pace of business hasn't accelerated though and that mismatch is going to become more and more apparent. So I was at a client, they were showing they were spending $2 million a year on some SaaS product. Somebody vibe coded a replacement for it that was better for their uses and didn't cost $2 million a year. How is that vendor going to reply to that? Back in the olden times, two years ago, they'd have years to respond to. Yeah, we have this add on. It costs $2 million a year but people don't really like it and eventually they're going to find a replacement. We have five years to respond to that or three years to respond to that. Now they've got, we have this add on, we've been able to charge for it. That's going to go away in a month. On their side, they could they code up a replacement that was better. Yeah, they could code up. They're seeing the same kind of acceleration everybody else is. But is the need for a replacement going to go through their customer service to marketing, to sales, to business development, to the product organization? Da da ba ba ba ba ba ba. That's that chain is designed to take five years and now they have a month or they're going to be losing big chunks of revenue. This isn't AI's fault, this is just an acceleration and their business process is just not prepared to respond in time. As my, my personal definition of agile is responds in time and they're not prepared to deal with the new pace. Like you, you're driving a tractor, and all of a sudden you're in a race car. Still wheels, still an engine. But are your skills prepared to steer that car? Not how fast can it go, but how fast can you get from point A to point B on a windy mountain road? You're used to driving a tractor, and now you're in a Ferrari. It's not the car's fault, but I think that's. That's a trend that I expect to play out, that we're going to see companies fail because they don't respond in time. They've. They've been fat and happy. Kind of newspapers with another analogy is newspapers with classified ads. Classified ads paid for reporters and paper, print, you know, stuff printed on paper and taken around everybody's houses. And then classified ads went away and journalism had to respond. And it's responded well in some ways, but poorly in others. And we're less served by local journalism than we were before all this happened. Okay, so now we have people who've been able to rely on switching costs to protect their profits. And the switching costs just drop to zero. Their profits are going to drop to zero. And some people aren't going to survive that change. Some people will. The flip side, so you're paying for some service. You think, I could vibe code something better. And so you do, but you only solve this much of the problem. It's the part the iceberg you can see that you can vibe code the part of the iceberg that you can see. So I'll talk my own book. I was at Gusto for three years. Does small business payroll. Somebody said, well, I just asked Claude, I have this many hours at this rate, I'm in this tax bracket, what should my paycheck be? And it tells me all the numbers. I don't need Gusto anymore. I'm just like, oh, you have no idea. Go ahead, run your own payroll for a quarter and then figure out what all of the reports you need to submit to the various tax agencies in different states. And I live in this one, but I work in that one, and the company's based here. And now. What should the number like? There's so much that goes on to correctly compliantly execute payroll that isn't gross pay, net pay. So we're going to see people get into those where they're like, well, I vibe code the tip of the iceberg. I throw away the rest of the iceberg. And now I'm in trouble because Now I don't know what to do. Now I get to these downstream problems that I didn't even know existed. So we're going to see on the, on the side of the vibe, coding replacers. We're going to see that kind of naivety play out.

[Interviewer (possibly a software engineer or tech journalist)]

And what about for software engineers? Because a lot of the identity for engineers was around being able to craft code, caring about the craft, being able to visualize a lot of these things. And these tools are getting really good at doing a bunch of that stuff. What advice do you give to these folks on. Okay, well there's this new technology change. If you'd like to stay top of the game, Software engineer, what activities can you do? What mentality change? Should you too?

[Kent Beck]

So the. My inspirational motto is nobody knows. So people come to me and they say, well, how does TDD apply in the, in the augmented coding world? I said, nobody knows. It's not just that I don't know is nobody knows. The big lesson I learned at Facebook was about that there are three different phase states of a product of software development. This exploration phase where you gotta try a bunch of different things cause you can't predict, then something takes off. And we've talked about a bunch of those examples from my career. And the discipline of riding that rocket up once it's been lit is very different than the discipline. And it is a discipline of exploring the space. So while you're expanding, you focus very intently. And it can be, and it might even be unsustainable, but it doesn't last very long. And then there's another. You get to extracting value from that to feed the next set of explorations. This is 3X, right? Explore, expanding.

[Interviewer (possibly a software engineer or tech journalist)]

This is yet another model that you came up sometime in 2016. 17.

[Kent Beck]

Yes. 15. 16. I finally figured out, figured out. I felt that I understood how Facebook had been able to be large, growing and innovative at the same time. And it was by treating projects at different phases in a completely different style.

[Interviewer (possibly a software engineer or tech journalist)]

So explore.

[Kent Beck]

Explore is you're just looking for something and you can't predict, so you have to try as many. It's a numbers game. You try as many uncorrelated experiments as you can for the cheapest price. Then you expand and then something takes off. And then you're in this expansion phase where instead of trying a little bit of everything, you focus on the one thing that's working and you discard everything else and you overcome obstacle after obstacle after obstacle. And then you get to a certain size and now you can predict growth and you can say, you can write a. If we roll out our product in a new country, we've done five countries already, here's the playlist and you know how to do that. That's that extract phase. You've reached economies of scale. You can make small tweaks and it makes a big difference. You have a long lifespan also. So how you write code, how you manage projects, who you hire, how many people, what the org structure is, is completely different in the three phases. For 20 years we've been up in that extractostan, there's been a playbook. It's evolved a little bit, but you know, oh, we have too many bugs in production. Here's the three things you can try. Oh, you know, we need to accelerate development. Here's the things you can do. People sometimes didn't do the things, but the playbook existed. And to be a senior engineer meant that you knew the playbook and the more you knew the playbook, the more effective you could be if you knew, oh, I also know how to scale backends. You know, I know about item potency and you know, what advantages that brings if I implement it and so on. Nobody knows now that playbook has been wiped clean and people whose identity is I know the playbook are now terrified. Who am I now? It turns out that the skill of writing a playbook is completely different than the skill of applying a playbook. That stuff that we did in the days of objects, that was writing a playbook, that was that explore part of the curve. It's not that there isn't a way to be effective when you don't have a playbook, it's just that it's a different game and the people who don't feel safe without a playbook need to turn their heads around just like, well, nobody knows. It's not like there's some secret playbook for GENIE based development that, you know, if only I paid a million dollars I could have just doesn't exist. When we get glimpses of it, it changes next week. Like small changes to the inputs cause large changes to the outputs. So we're all back in Explorer stand in this where we just. The more things we can try, the better I'll get these questions. Oh, I think we should, instead of writing one test at a time, maybe we should write a bunch of tests at a time. Do you think that would work? Nobody knows. Try it and tell us how it goes. If more people are trying more things in community and communicating like, I did this thing here, I added this Markdown file. And it had this effect. Somebody else says, well, I added it and made things worse. Okay, well what's different about your have to have that conversation. That's what's going to result in the playbook. The agile manifesto date 2002, right?

[Interviewer (possibly a software engineer or tech journalist)]

2001.

[Kent Beck]

Yeah, 2001. The first. Oopsla. 1986. Took 15 years to write that manifesto. Which is why when I see manifestos today, I'm just like, too soon. Not a bad idea. Would love to have one. Just too soon. It took 15 years for the technical change of object oriented programming to come before we could say, here are the consequences of it, here's how in a simple way we can express how to effectively use this technology that we've been using day in and day out for 15 years. The Genie comes along, people are like, well, what's the new manifesto? It's just not manifesto time yet.

[Interviewer (possibly a software engineer or tech journalist)]

As closing, what do you find exciting? Looking ahead with AI agents, with genies, with all this change, with this clean state that we're in, what gives you energy?

[Kent Beck]

This is home base for me, the writing of the playbook. I just love that I'm a tree shaker, not the jelly maker. So I love shaking the tree. I love getting stuff started. I have a very wide range of projects. So I have project called Arlo, which is a. An object oriented database. I have several fundamental data structures. I wanted to see if I could write code that was library quality code for a language I didn't know. It turns out, yeah, I can. So I built a B plus tree that faster than Rust's B tree for some operations. Wow. Wow. Yes.

[Interviewer (possibly a software engineer or tech journalist)]

But also

[Kent Beck]

I'm not a Rust expert. Like what could a Rust expert do with these same tools? And why didn't they write it? I don't, I don't know. But I'm building little bits and pieces of apps for stuff that I care about. I use the GENIE for business planning because like you, I have a newsletter. Unlike you, my newsletter is kind of small, but it's pretty big. I'm doing okay now. How do I turn that into a sustainable business? Also, I hired a business partner to help with that. So I'm doing a lot of writing, reflecting on my experiences. I'm trying everything. If there's a secret sauce to what I'm doing, it's not being afraid to start over.

[Interviewer (possibly a software engineer or tech journalist)]

And, and your, your whole, your whole career shows this from the very early days. TDD XP3X Heidi first genie.

[Kent Beck]

Yeah. So if you look on my GitHub, you'll see project, project two, project three, project four, new project, new project two, new project three new projects. I, I'll take it, I'll push it a certain amount and then the genie runs out of ga, runs itself out of options. It can't make further forward progress and so I'll wipe it away, start over. I won't try and tweak. I'll start over and say, all right, well, if I implement things in a different order, if I implement with this markdown file, or if I implement it with this commit hook, we collectively need to try absolutely everything. And some of those ideas are going to be sound stupid and are going to work out great. Some of the stupid sounding ideas are also going to be disastrous. But if we're willing to start over, then it doesn't matter. We're not really risking that much. That creative impulse is what's come back to me with the genie. This idea that I can go, I wonder what a B plus tree looks like in God. Here's an alternative to the B tree, this adaptive radix tree. What does that look like? I can find out. I sit down with a genie, I can work it out. And then there's this artifact that wasn't there before, that's there now because of my imagination and my work. And I had gotten fed up with the stupid minutiae of programming. Oh, for that you need to have the version 7.1 of the upgrade, the thing which then causes something else to break, which causes something else to break, which means that I can't use version 7.1. I have to. I just hated that. Getting emotionally invested, having an idea, getting emotionally invested, getting a ways in and realize I can't do this for no good reason. I hated that. And that that kind of blockage just doesn't happen to me now. And oh, so it's. This is hog heaven. I've got 40 years worth of ideas. This would be cool. Ugh. It's too big that suddenly are back in play. And I'm having so much fun making things that are real.

[Interviewer (possibly a software engineer or tech journalist)]

I can see it on your sharing it as well. Kent. This was awesome, especially doing it finally in person.

[Kent Beck]

Yeah, it was great. Great to be able to sit down with you in your home country. Here we are.

[Podcast Host]

This was a special episode for me, recorded in Budapest, Hungary, right before craft conference 2026.

[Interviewer (possibly a software engineer or tech journalist)]

It was a first getting to hear

[Podcast Host]

Kent walk through his entire career, start to present in a way he's never done in a podcast before. One thing I think back to is how Kent said we're accumulating code faster than we're accumulating trust.

[Interviewer (possibly a software engineer or tech journalist)]

Kent is so good at summarizing very true things like this.

[Podcast Host]

When you struggle through understanding domain, represent it in code, and write tests that prove that you got it right, you

[Interviewer (possibly a software engineer or tech journalist)]

end up trusting your program.

[Podcast Host]

And when you do that work alongside other people, you build trust with these people too. Ken's point is that none of this happens when you just prompt an AI, or as a genie he calls it, and you get back the code that

[Interviewer (possibly a software engineer or tech journalist)]

works and the AI says it's all done.

[Podcast Host]

I also loved how consistent Kent has been across 50 years. Whether it's small talk, design patterns, TDD or AI, today his instincts are the same. Try the stupid idea and don't be afraid to throw it all away and start over. As he put it, he's a tree shaker, not a jelly maker. And Ken's tree shaker impulses right back

[Interviewer (possibly a software engineer or tech journalist)]

on and is trying stupid things with AI.

[Podcast Host]

Finally, I appreciate how grounded Kent is. People kept asking him what the new manifesto for AI development is and his answer is that is too soon. The agile manifesto took 15 years of doing object oriented programming before people like Kent could summarize lessons with AI. Things are still changing quickly and Kent is honest when he says that right now nobody knows what is working do. Check out the show and below for

[Interviewer (possibly a software engineer or tech journalist)]

how Kent and me both thought that

[Podcast Host]

McKinsey did not know what they're talking about when they want to measure software engineering productivity.

[Interviewer (possibly a software engineer or tech journalist)]

Also check the show notes for related

[Podcast Host]

the Pragmatic Engineering deep dives on topics like tech depth, software craftsmanship, TDD and others. If you've enjoyed this podcast, please do subscribe on your favorite podcast platform and on YouTube. A special thank you if you also leave a rating on the show, thank you and see you in the next one.