Unlocking AI Development: Insights from Kent Beck

Adam Davidson: 00:00:00

Hi, this is Adam Davidson, one of the co founders of FeedForward. And I have to say this is a conversation I've been wanting to have for a long time.

You know, a lot of us are starting to build things with AI, vibe, coding, writing little scripts, making tools for ourselves. And it turns out there's a whole body of wisdom about software development that is suddenly incredibly relevant to all of us.

Today's guest is Kent Beck. If you don't know his name, you've certainly heard his ideas. Test Driven Development, refactoring, Agile xp.

He invent or co invented a remarkable number of the foundational concepts in modern software.

He's a thinker and a developer and as you'll hear, almost everything he figured out about how to build software maps directly onto how we should be thinking about building things with AI right now. It is a real thrill to talk to Kent Beck. Hey, Kent.

Kent Beck: 00:00:50

Good to see you, Adam.

Adam Davidson: 00:00:51

Yeah, good to see you.

You know, I'm not a software developer, but I'm a sort of fan of, and I've been around software development and there's a bunch of terms we use that to me are just like, oh yeah, that's that thing that people do. And a surprising number of them are actually terms you invented or were part of a team that invented.

So Test Driven Development, Refactoring Agile, and Agile xp. We could go on.

But I kind of think of you as like a, I don't know, is it fair to say like a philosopher developer or a thinker about the process of development as well as a developer,.

Kent Beck: 00:01:29

I can't help doing both. And I've had the good fortune to be dropped into some situations where that combination seemed to have leverage.

So that's what you make a career out of, I guess.

Adam Davidson: 00:01:44

Yeah, exactly.

The other thing I'll say about your idea is I don't know that I could name a lot of other developers by name, but your ideas for me as a layperson, as a non developer, are really accessible.

And that's why I've been thinking about you a lot the last few weeks and months and was eager to talk with you because I mentioned to you, our members, the people listening to this are executives at big companies. Most of them are not developers. Most of them, I'm guessing, have never really thought that much about development.

Development was like a technical thing a bunch of people in another part of the building did. And you know, maybe once or twice in a career you'd be involved in some project, but probably not where you had to work with Developers.

And suddenly we're all sort of developers and we're all interacting with software development because of AI. And I certainly am constantly just building tools and playing with code and there's like Vibe coding.

Simon Willison, who's one of our experts, you must know Simon. Do you know Simon?

Kent Beck: 00:02:49

I certainly know of read his stuff.

Adam Davidson: 00:02:52

Yeah. Because I would say the two of you occupy a similar place in my brain as extremely thoughtful developers who connect software to the greater world.

But, you know, Simon likes to point out that a lot of these terms are poorly defined. What is Vibe coding? You know, is Vibe coding just anyone typing into Claude more than a chat? Or is Vibe coding a real thing?

But what I'm finding as I start building tools, mostly for myself, but beginning to build tools for other people, what's thrilling about this moment is I don't feel like I have to learn Python or learn Go or learn some other language, but I do find there's stuff I need to learn from people like you, and you are the person I want to learn them from.

So that's what I wanted to talk about is sort of what do software developers know and think about that endures in a world of AI coding that is still relevant? And we can also talk about what maybe you don't need so much, right?

Kent Beck: 00:03:52

What endures about software development. What endures about software development is that is change.

So if you believe that your understanding of the situation is going to change and you believe that the situation itself is going to change partly in response to the actions that you take, then trying to get everything right up front and kind of the way I was excited to see spec driven development because it just sounded like TDD for genies. So I called the models a GENIE because it grants your wishes, but it turns out not to be what you asked for, what you intended.

You get what you asked for, not what you wanted.

Adam Davidson: 00:04:40

That's a good.

Kent Beck: 00:04:41

So the genies, I thought spec driven development, that just sounded like test driven development for genies. I thought, oh, that'll be cool.

And then the other shoe dropped and was like, we'll just get the spec right up front, the Genie will chew on that and then we'll get exactly what we want out the back, which, which contradicts change. That's only true if, one, you don't learn anything, and two, nothing changes, especially. And.

And those are the two most valuable things, especially when things change as a result of the actions that you've taken. So you build an app, it goes out there, somebody goes, oh, this is Fantastic.

I can also use it for tracking phishing, but I'm going to need some more features. Well, you could not have anticipated that, right?

Adam Davidson: 00:05:39

I'm taking Tibetan right now and I was looking for a flashcard app and I just didn't like any of the flashcard apps that I found. So I thought, oh, I'll just make my own. I will say. My friend who's a software developer looked at my code and said, this is horrible.

And a friend of mine who's a designer looked at my design and literally laughed at how horrible it is. And I'm like, I don't care. I love it. It's. It's exactly what I want. And.

But I had a vision for it that changed the second I saw something usable and continues to change almost every time I use it. I'm like, oh, what if I could add a picture? What if I could add the sound of my teacher saying that word? What if I could sort this way?

What if I could only look at words that are about the body or only look at participles or whatever? And I just, I had a vision. I thought I had a complete vision.

And this is a very simple tool, but if you start imagining building something like a CRM, Accounts receivable software, Accounts.

Kent Beck: 00:06:37

Receivable, warehouse management, air traffic control, you name it, the release of the software into the world changes the world in ways that change the requirements of the software. That's, that's just stone cold facts. And I understand that goes contrary.

People want to say, I get this question all the time, well, what am I going to get for my money? I don't know and you don't know. And if somebody tells you they're at the very best, they are pandering, if not outright lying, because change.

So if we assume change, if we assume no change, then all bets are off and things are easy and. But it just doesn't work over and over again.

If we assume that things are going to change, that implies that we have to work a little bit at a time, in cycles, and be prepared to adapt to the feedback that we get. That also implies that we care about the structure of the code because it's going to have to change.

And changing code is harder than writing it in the first place. And that also flies in the face of not conventional wisdom about this augmented development.

Well, so vibe coding versus augmented development, that's a distinction I make. Vibe coding. You don't care what the code looks like.

If somebody says this code looks like crap, you don't take it Personally, because you just don't care, because you just never even look at it.

Adam Davidson: 00:08:15

You might not even know what language it's in or what framework it's using.

Kent Beck: 00:08:20

Right.

And you may not know the language, you might not be able to read it, but you don't care because the GENIE keeps adding the next feature which works until it doesn't. The genie adds complexity at a rate greater than its ability to handle that complexity.

If you stop your flashcard app before you get there, you're good. Yeah, who cares? Doesn't matter.

But if you turn out to need that optionality to need the ability to continue making changes, then you're going to have to divide your mind a little bit between or your investments. We'll say you'll have to divide your investment between adding features and improving the structure to make that software more changeable over time.

Adam Davidson: 00:09:14

Right.

Kent Beck: 00:09:14

And that second part, genies suck at.

Adam Davidson: 00:09:18

They really suck at. Yeah, yeah. And I wanted. Right. And I want to dig into that. Let's set the stage because I've been. I was talking to my dad's first cousin.

She's in her 80s and she was a software developer in the 60s. She actually worked on the Apollo mission, the Apollo 11 mission, and then has been a soft.

I mean she's retired now, but was teaching until very recently.

And she told me about develop software development in the 60s and 70s and she said the way it worked is there'd be a bunch of meetings, like a lot of like months of meetings. They'd come up with the whole thing. They'd spend five years building it and then it never worked. And then the project died.

And she saw that happen over and over.

Kent Beck: 00:10:06

And then you start the next project in exactly that, exactly the same way.

Adam Davidson: 00:10:10

Exactly.

I will say, I like to say about Diane, that Diane Martin, you know, it's a woman developer because she was like, oh, I didn't really do much on Apollo 11. The only thing I did was the code that made sure the rocket stayed on its trajectory in space.

And I was like, if any man had done that, he'd be like, I am responsible for the loot. That seems like a pretty big deal, I gotta say. Um, yeah.

So I think of the 90s as a period of dramatically reducing the time between hey, I got an idea and here's a bit of code and I see you as a key part of that. So maybe talk a little bit about what was going on for you.

You actually, you may not even remember this, but like a year ago you told me this story on the phone or two years ago, maybe. But what was going on for you? The ideas that eventually led to Agile and XP and TDD.

Why did it seem important to not spend 5 years building useless co?

I mean, now it's the kind of thing where now it's so obvious and the second you hear it, it's obvious, but we had like a generation or two of very smart people doing it this way. That now looks utterly idiotic. So tell me about, you're younger than Diane, but what, what was going on when you were like, this isn't working.

Kent Beck: 00:11:29

Yeah. So I, I, one of the driving factors is my, in my life is that I hate to waste time. I have a keen sense of the preciousness of every second.

And the human lifespan now is about 3 billion seconds. That's 92 years. And you know, every second one of those seconds ticks away and never comes back.

So I hate, hate, hate wasting time on stuff that doesn't matter. When I went to programmer school, this, this waterfall, let's get the specifications right up front.

Adam Davidson: 00:12:09

Right. That was, it was called waterfall. Why was it called waterfall? What is the idea there?

Kent Beck: 00:12:14

It's back to a paper that was by Winston Royce that was misread. He, he, he said, okay, we're going to make the analysis decisions.

You know, what features do we have then the design decisions, kind of the structure, then the implementation and then the test. And, and he drew it like that. And he said, of course this doesn't work. If you go back to the original paper, of course this doesn't work.

Of course there's feedback loops going back the other way. But people took, I mean, this is the power of an image.

People took that stair step and thought, wouldn't it be wonderful if that's how the world worked? And they've cost themselves trillions of dollars trying to pursue that illusion that you.

Adam Davidson: 00:13:01

Have a long period of planning, you plan the whole thing, then you write all the code and then you find out if it works. And when you find out if it works, you find out it didn't work. Like the vast majority of them, the.

Kent Beck: 00:13:13

Underlying embedded assumption there is that things aren't going to change.

Adam Davidson: 00:13:18

ht? That whatever you knew in: 1972

And there's not going to be one additional thought to that needs to be accommodated. No edge case. No.

And, and obviously we all know like the second you get Microsoft Word or whatever program, it's not just you continue doing things the way you did them, but now with a computer like it, like you said, it changes everything, right? Like sales is different to the salesforce.

Kent Beck: 00:13:45

Yeah. And that's why the, the extreme programming book is subtitled Embrace change. We're just gonna take the opposite. So this is 97. 6 About that.

I've been doing experiments. I didn't believe this. This waterfall fairy tale. I've been doing experiments with team process that was more aligned towards change.

And then I had the chance to lead a team that was working on a critical piece of financial infrastructure and kind of under the gun to make Y2K and thought, well, let's just, let's just do everything backwards of the way I'm told. Let's see how little we can write down up front. Let's see how often we can integrate the software.

Adam Davidson: 00:14:41

Because test driven development, I mean, that was just tdd. You tell any software developer, you tell Claude. Tdd. It knows what you're saying. Yeah, it's a crazy idea. Like it, It's. I can. It's.

And just so the listener understands, you write a bunch of tests. And the obligation. No, oh, I'm already wrong.

Kent Beck: 00:15:05

Okay, you write a test, you think of all the tests that you want to write, but you don't worry about specifying them in precisely because you don't know yet. If you assume that you're going to learn new stuff, you don't want to write a bunch of tests. You have it in mind.

Okay, so your flashcardy thing, okay, we got a flashcard, and then we have a flashcard and the text is empty. Oh, no, we have to handle that correctly, whatever that looks like.

And then we have one with a picture, then we have one with picture and sound, then sound and no picture. And I think that's everything. Now the text is too big for the space. I think that's everything I can think of. The way TDD works is.

Now imagine, Step back a second. I want all five of those scenarios to work when I'm done.

The backwards way to do that is to take one of those scenarios, probably the simplest one, and write a test that says make a flashcard and there's some text and I make sure that the text displays correctly and I'm done. Except I know I'm not done. I. And I write the test. It says, no, it doesn't work. And I say, oh, okay, okay.

And then I code up a little bit or the genie codes up for me and now makes that one work. And now I look at my list and I say, well, what's the next one that I Want to look now? What if there's text and sound? Okay, let's try that,.

Adam Davidson: 00:16:41

Right? And I gotta say, the first time, like, I've, I've known about you for a while and I knew about test driven development, I didn't know what it was.

And so the first time I just was using cloud cold and said, let's use TDD for this, because that sounded cool to me. But I didn't know what TDD was other than some vague sense that testing was involved.

And then the very first thing that happens is says, we wrote the test and good news, it failed. And I'm like, oh no, the test failed. But that's what you actually want. So it's like I'm going to create a flashcard, text on a card, run the test.

There's no text on the card. In fact, there's no card. That's the first step.

Kent Beck: 00:17:28

Now, you know, with much greater precision than you knew before, you know what you need to implement. Not all of everything that you need to implement, but the next step is clear.

Adam Davidson: 00:17:44

And again, you can imagine. So if we are in a universe where software developers have been trained that testing is the final step.

It's like month eight of the fifth year of some massive development process and you're saying, write the tests first. People must have laughed at you, thought that was the dumbest idea they ever.

Kent Beck: 00:18:05

Heard because it's backwards. You want the test to pass. So here you are writing the test at the moment. You know it's going to fail because you haven't even written any code yet.

So you write it. Usually you write a test and you're like, you know, coin flip, is this going to pass? Is it going to fail?

And you know this is going to fail because I haven't even implemented anything yet. It's guaranteed to fail.

Adam Davidson: 00:18:31

So is the reason. And we should just say like, yes, in the 90s, people after you now. It's the standard. I mean, there's, it's a.

Well, but maybe not the standard, but no, no, it's well respected if not well followed. Is that.

Kent Beck: 00:18:46

Yeah, yeah, yeah. No, big time lip service, Big time slip service.

Adam Davidson: 00:18:50

Because it's weird. It's a weird idea, right?

Kent Beck: 00:18:53

It, it twists your head around. Absolutely.

Adam Davidson: 00:18:55

Like if I'm cooking dinner for my wife and I'm like, hey, look, I burnt the chicken, you know, that's not a good first start.

Kent Beck: 00:19:03

And that's because your chicken is not reversible.

Adam Davidson: 00:19:07

Right.

Kent Beck: 00:19:08

You can't just uncook it with the way you can easily in Software.

Adam Davidson: 00:19:13

So, okay, so the reason for I want to get. Because remember, the point here is not to train a bunch of people in software development.

The point of this conversation is to help people get a mental frame for how to think about software development.

My assumption here is that every member of FeedForward, every executive, is going to be probably doing two things at least over the coming years, if they haven't already. One is working more intimately with developers.

We're already seeing companies moving develop software development out of a sort of isolated castle and just sending them out. Here's a developer that's going to just sit with the marketing team.

Here's a developer who's going to sit with sales and they're just going to like code stuff alongside the subject matter experts. But I also think a lot of people,.

Kent Beck: 00:20:05

I laugh because I published a book 25 years ago that said to do that and everybody said, whoa, well, if we had the luxury of sitting with the people who were using the software. And I said, well, why is that a luxury now? It's not now it's not.

Adam Davidson: 00:20:19

Right. That's amazing. Yeah, well, that's why I'm talking to you, because I feel like you sort of created the guide to this world.

So, so I'm trying to get people, and one of those people is me, a mental frame for how to think about this. So to me, the reason test driven development helps and we'll get to your other insights as well.

And part of it is it does make you think, okay, I want a card. So how would I know if I had a card like it would like, would it be the full screen? Would it be 3 inches by 2 inches? Would it be.

Kent Beck: 00:20:54

That is exactly the question. How would I know? That's the, that's the big transition. Usually, usually as a programmer you go from vague idea to here's how I'd implement it.

And in test driven development, you go from vague idea to here's how I'll know when I'm finished. I don't, I still don't know how I'm going to implement it. Maybe I have an inkling, maybe I don't. Doesn't matter.

The first step is just how will I know when I'm finished? Which is effective leadership behavior regardless.

Adam Davidson: 00:21:31

Right, right. And that, that to me, and we're going to get there soon.

Like, I feel like everything I read by you, there are technical stuff that you know, you need to know a little bit about code. But it is, it's sort of like you can apply to life. Like you could imagine. You know, my son is 14.

I'm having some conversations with him that are pretty intense about like all the things a 14 year old boy goes through. And I can't go into those conversations with a really firm, like, here is how he's going to feel.

I, you know, I'm now in a place where like, as far as I know, he hasn't yet done the things I did in high school. But I want to kind of know like, what is going to be a sign of, of a good outcome if something goes wrong.

Like, you know, I had a, you know, like I had a talk with him about, you know, if you're ever in a situation where it's not, you don't feel safe with the people you're with and even if substances are involved, you can call me a mom and we'll come get you and you won't get in trouble for that. And like that's an ex to me, that's somehow related. It's like I can't guy, I can't make him do stuff. I can't force him to behave in a certain way.

But I can start imagining the kind of relationship I want and the role I want in his life and describing success conditions. And you can also do this with like expense software or whatever. Or whatever it is.

Kent Beck: 00:22:57

Yeah, or a business venture.

Adam Davidson: 00:22:59

Or a business venture. Okay, so we start with the simple test, then the next test, then the next test.

Kent Beck: 00:23:09

And, and so we cross them off and along the way we may think of new tests. We may think, oh, what if, what if the picture is zero size? I didn't think of that up front. Well, that's fine. Just add it to the list.

We won't say we're done until we've crossed that one off. We don't have to do anything about it right now. That's fine.

Adam Davidson: 00:23:31

That's fine.

Kent Beck: 00:23:32

So it'll just, it gets added to the list and eventually though, we cross off all the things on the list and then we're as done as we know how to be right now. And if ever we want to know, does this work, we push a button and all the tests that we've already written and have made pass will all run.

And if they're all green, things may still be messed up, but they're messed up in ways that we can't anticipate, so we don't worry about that. And part of the skill is being able to anticipate more and more stuff.

But I, so for executives, I wrote a short book for O'Reilly called the Good news factory, which seems to have vanished without a trace. But I mean, it still exists in the world.

But the idea was, what would it take for software development to be a source of good news instead of bad news? What, what, what stance do you need to take as a leader so that that's true? What, what levers can you pull?

And it turns out there's a lot that you as an executive can do to create the conditions in which you can get good news regularly from software.

Adam Davidson: 00:24:53

Development, as opposed to the kind of like, wah, wah. No, you don't get to do that. No, that's too expensive.

Kent Beck: 00:24:59

No, no, we're all booked up. Yeah. Oh, that thing we said was going to be done today won't be done for four more months. Oh, we have to write the software over from scratch.

All that stuff that we did, we have to throw away because none of it's useful. That's, that's the bad news factory. Yeah. And, and that, that leads to, just at a human level.

Human to human level, at least to a horrible relationship. Nobody wants to deliver that kind of bad news and nobody wants to hear that kind of bad news all the time.

So no wonder they sequestered software development often, some little room someplace and slid hot dogs under the door, because who wants to be part of that dialogue? And my vision is no teams can deliver good news.

And somebody says, oh, you know, the salesperson says, oh, I wish, sure wish the software could do, blah, blah, blah. And the programmer says, oh, turns out that's easy because we did our homework.

Adam Davidson: 00:26:01

I wrote this book called the Passion Economy, and one of my heroes in the book is this accountant who just got sick of being a guy. Nobody's like, oh, I'm super psyched, I have a meeting with my accountant. It's like, you gotta file taxes, you got an audit.

And he just kept thinking, what if people were excited to see me? What would that be like? And what would get me there?

And it took him a long time, but he came up with a way of being an accountant that is transformational and positive and not just, well, you need an accountant. So.

And I want to move into Agile xp and there's some ideas that seem weirdly prescient, like this idea of pair programming, which to me, when I first heard about it, felt weird, like I don't know that. And so explain what it is and why that was an effective idea, because now I'm thinking it makes even more sense.

Like pair programming with two coders is one thing, but pair Programming with a subject matter expert and a coder seems.

Kent Beck: 00:26:59

Like can be magic.

Adam Davidson: 00:27:01

Absolutely.

Kent Beck: 00:27:02

So back in the day, there weren't enough teletypes in the machine room. So you'd have some program you were working on, but there wouldn't be any teletypes available.

But your buddy is sitting there working on something else. You'd sit down and you start shooting the breeze. He, they, they would say, well, you know, but it's getting stuck here.

And you, well, what about this? And you'd have this conversation and make some changes and run it again. Look what came out. Have some more conversation. Look what came out.

Then everybody had a computer and now everybody could code alone. And the, the superficial analysis, that's the word I want to use. Superficial analysis is twice as many people typing will go twice as fast.

But the problem is it's not a divide and conquer world. It's a divide, conquer and integrate world. And that integration step can easily hide bad news.

Exactly the kind of bad news that, oh, well, we thought we were finished, but it's going to take two more months to put all the pieces together. Or we thought we were finished, we put it into production, and then we discovered that it's going to take two more months to put the pieces together.

That's the worst news possible.

Adam Davidson: 00:28:24

Right.

Kent Beck: 00:28:26

And so I had had the experience of this kind of two people sitting in one machine, a conversation that results in software. And Ward Cunningham was my partner, the guy who invented the wiki in that he was my mentor when I first came out of school.

And he went on to teach that at his next job, he just told people, well, here's how you program. Two people sit down together and you have a conversation that results in a program. Okay, I guess that's how you program. And so they started doing it.

So on the micro scale, it looks like it's wasteful, but in the macro scale, because you're sharing so much more information, because you're building social ties every day, it turns out overall, to produce more and better software, build stronger teams, create happier customers, and as you say, it's not limited to programmer talking to programmer. You can, you can pair across domains, which can be really powerful.

Adam Davidson: 00:29:40

Yeah, it reminds me of when I was at NPR as a reporter. A lot of reporters report to their editor, who often is the same. They know the same stuff.

So I was a business reporter, my editor was a business reporter, was a business editor.

And that means we sort of speak the same language, we have the same frame of reference, and very often I felt some of our content wasn't that great because we didn't realize we had to explain an idea. We didn't realize there was actually an opportunity for something kind of interesting and weird because it was just so familiar to us.

But when I was paired with a producer who didn't know anything about the subject matter, but maybe had a sense of how to structure a story and how to make a radio piece playful, it was so much better. And so to me, it just seems.

Kent Beck: 00:30:29

Yeah, but wait, wait, wait, wait, wait. But you see, you have to slow down. You have to slow down and explain stuff to that person.

Adam Davidson: 00:30:36

Yeah, exactly.

Kent Beck: 00:30:37

Losing. You're losing productivity, Adam.

Adam Davidson: 00:30:40

Well, this is an actual fight I had with my editor. Literally, this.

I did this hour long special on the financial crisis for this American Life and called the giant pool of money, which really changed my life. I mean, it, it was the most, it won lots of awards anyway. It was. And it had a huge impact on a lot of people.

And my editor at the time was like, you spent three months on that. You could have done a.

You know, and he did the math on how many pieces I could have done instead of this one thing, which I did with my friend Alex, who didn't know the topic, and together we did this story. And I was like, he's like, is it really worth whatever it was, you know, losing five times as many minutes of radio?

I was like, yes, it's infinitely better. Like, there's no comparison nobody would ever think about. I could have done, you know, I think I spent four months on it.

If I had done three stories a week for four months, whatever that adds up to, you know, 50 stories, literally not one of those would be memorable. And, and, and so it, it's infinitely more valuable. But just to someone like that, the mentality is. Yeah, why.

You know, we're just optimizing for output, not for quality times output or whatever the metric should be. So.

Kent Beck: 00:31:55

Yeah, that's exactly something about. I mean, in that case, the, the metrics are something about an informed society making informed choices.

Adam Davidson: 00:32:07

Yes, exactly. So, okay, which is.

Kent Beck: 00:32:10

But that's, that's hard to measure. I mean, we could get on to the whole metrics and measurement thing, but I'm going to let you ask questions.

Adam Davidson: 00:32:17

No, no, that, yes, there's so much here. You're right. And I mean, in a way that is, though, sitting on top of this, what are you optimizing for? Correct.

And are you optimizing for lines of code for commits, or are you optimizing for actual impact on people's lives, whether that's people within a company or around the world or.

Kent Beck: 00:32:43

Right. If you run a mine, you're not optimizing to maximize the amount of diesel you burn.

Adam Davidson: 00:32:51

Right.

Kent Beck: 00:32:51

You want, you want to know how much gold comes out of the ground.

Adam Davidson: 00:32:56

Right? Exactly.

Kent Beck: 00:32:57

And many of the measurements that we have in the software world are akin to how much diesel did you burn.

Adam Davidson: 00:33:06

Yes.

Kent Beck: 00:33:06

Just like, yeah, the lines of code or numbers of commits or hours spent, all that stuff is about the consumption of the raw resources has nothing to do with, you know, in the case of npr. Do you have an informed electorate?

Adam Davidson: 00:33:25

Right, right. They're not even proxies for the thing you're measuring. They're just an irrelevant.

You might as well, you know, how many calories did you consume while creating that story? Or how many molecules of oxygen or whatever. So I want to get through the kind of Kent Beck oeuvre because I want to then update. So.

All right, so test driven development, crazy idea, super effective, at least conceptually changes how people think about programming if not in practice. Although I think there are a lot of test driven developers, aren't there?

Kent Beck: 00:33:56

100%. Yes.

Yeah, but, but in terms of percentage and if you, if you look, people say that they're doing it and not doing it is pretty common because it's, it's hard. It's a different kind of hard work.

Adam Davidson: 00:34:11

Yeah. And it's a different kind of leadership. It's a boss who can, who has an employee who says, oh, I'm going to try this. Oh, it didn't work.

And it's like into that. Is it different? Like there's a lot of bosses who are like, I need to know exactly what you're going to do, I need to know when you're going to do it.

Okay, so there's test driven development. I want to get to refactoring because that feels like a big.

That was probably the thing I was most surprised to learn was someone's idea and that that person was you.

Because I just thought refactoring, that's just the thing that you do, which in software development is like your code is okay, but it works, but it's not great, so we're going to make it better. And I was surprised to learn what a radical idea that was.

That there really was the mindset in the, into the late 90s that if it's working, you're done with that, let's move on to something else. So talk to me about refactoring. What was that solving? Why was that A radical idea.

Kent Beck: 00:35:08

So back to this assumption that things aren't going to change. If things don't change, then we can decide today how the project will be structured.

There'll be these, this kind of stuff goes over here and that kind of stuff goes over there. And then maybe they talk a little bit back and forth, but not very much.

If nothing's going to change, we want to make as many of those decisions up front as we can because changing them seems to be really hard analogy. But would be something like figuring out exactly where all the furniture is going to go in your house. Because moving furniture is a pain.

If you're not going to learn anything, if nothing's going to change, that's probably fine.

But I said I make the opposite assumptions, that things are going to change, that we are going to learn, and that the release of the software is going to change the requirements for the software. Software. So if we make the backwards assumption, then we want to make those kind of structure decisions.

What, what stuff goes together and what stuff goes separate. We want to make those as late as possible instead of as early as possible.

Adam Davidson: 00:36:24

Well, I just wanted to zero in on at least how I understand it. But I might be wrong that it's not just, you wrote a bunch of software, now change it.

It's thinking, oh, I'm probably going to change this in the future, so I should build it so that it can be changed.

Kent Beck: 00:36:42

Yes.

Okay, so that's a, that's a good thought to have, but not necessarily a good action to take because as I get more and more skilled, I can think of more and more elaborate ways that the software could be. Should be structured. And I make it more and more complicated over time. So the, this incremental style.

Again, back to the assumption things are going to change.

So we're not going to think about all the ways the software might change, but we'll certainly take into account the ways the software is about to change, because that one's guaranteed. And that's why the title of the latest book is Tidy. First question mark is this moment where you say, I got to change this code and it's a mess.

Should I tidy first? The answer is probably yes, but not too much. The kind of changes you're making to prepare for a change shouldn't appear to any outside user.

It'll change my experience of the code or my genie's experience of the code, but it won't change your experience as a user.

You'll see the same flashcards, they'll look exactly the same, just Internally, I've rearranged things so it'll be easy for me to add sound instead of looking at this big mess of stuff and saying, bolt this on here and that on there and shove a bunch of stuff together. And now sound works too, but that makes it harder to change the next time Refactoring, Is that.

Adam Davidson: 00:38:28

It is.

Kent Beck: 00:38:29

Is that making the internal structure of the code amenable to change and you do it a little bit at a time, just the same way you do everything a little bit at a time.

Adam Davidson: 00:38:44

Right. So if you then obsessively spend three weeks making it perfectly tidy, that's probably wasted time because you're going to make a change anyway.

Kent Beck: 00:38:53

And yeah, yeah, the next thing you add, you'll. You look at it and you say, oh, I see, yeah, we shouldn't. That's not how this wants to be structured at all. And then, right.

Adam Davidson: 00:39:06

I don't even want audio or I want video instead. And to do video makes the way I built the audio not make sense anymore. Because I like things I've come to.

I mean, through reading, like as I become a. I feel like I'm having a crash course and learning all the ways you can fail as a developer by failing. But it's rapid, it's very rapid.

Kent Beck: 00:39:32

I feel like I've probably ten times as fast. Yeah, yeah, congratulations.

Adam Davidson: 00:39:36

Yeah, I got like 10 years of failure in the last three weeks. And then I start reading about software and some people I read and I'm like, this is irrelevant to me.

Like, I'm not going to spend two years becoming a master at how to generate subroutines within Python or something like that, because the genie will just do it for me. But more and more I find your ideas. So I don't mean to just keep sucking up to you, but there's a reason I wanted to have this conversation with you.

So let's get to Agile because I would guess of all the ideas you've come up with, Agile XP is your baby. You are part of Agile as a concept. As I understand it, there was like 17 people, you were a leader among them who wrote the Agile manifesto.

But if we want to say like Kent Beck created this, that would be Agile xp. Can you just give us the Nichols tour of what is Agile? What is Agile XP and what was it it doing? Like, what problems was it solving?

What was it responding to?

Kent Beck: 00:40:39

Yeah, so it was responding to a bunch of people making this assumption that things aren't going to change, having horrible experiences and then making the assumption that if Only they did it better, nothing would change. And repeating that over and over again and the, just the sheer human waste of that.

Adam Davidson: 00:41:01

Feels like we've left software development into just life.

Kent Beck: 00:41:04

Like we're all doing that, right? Yeah, yeah, absolutely. Absolutely.

Adam Davidson: 00:41:08

This time I will.

Kent Beck: 00:41:10

That's right. I will plan my route perfectly and no roads will be washed out and. Yeah. No power lines will fall down.

Adam Davidson: 00:41:19

Yeah, I finally figured out how to have a relationship.

Kent Beck: 00:41:25

Yeah, exactly.

Adam Davidson: 00:41:27

Yeah.

Kent Beck: 00:41:27

Oh, painful. Thank you for bringing that up. So that's what I was responding to. And I wasn't hardly alone in that.

There a bunch of people were responding in various different ways.

And the people who were bought in, heavily bought in, who sold tools, for example, that embedded this assumption that things weren't going to change, you know, so we can just decide everything. Right now though, those people were starting to attack us. The. And, oh, this is irresponsible and it's not disciplined.

Well, it's way more disciplined to work in this change oriented style because you don't have a margin for error. You're driving a windy road at night, you have to be right on top of things.

So it wasn't true, but they could see that their livelihoods were threatened and they responded the way people always do when livelihoods are threatened. So we realized, no, we have to come together now.

Adam Davidson: 00:42:37

So, so just to be clear, so late 90s, there's a bunch of people thinking similar thoughts to you, which is like, yeah, yeah. And by a bunch, we're talking about like a dozen or two, not tens of thousands.

Kent Beck: 00:42:48

Okay, so there were people who rejected that, that dogma of nothing's going to change so we can do everything right now. There were people who rejected that, but they weren't proud of it because they were the cowboys.

They were, they, I mean, and some of them were undisciplined and, and you know, those efforts also failed. So that, that was.

Adam Davidson: 00:43:19

Sorry, just.

Kent Beck: 00:43:20

Yeah.

Adam Davidson: 00:43:20

In defense of your enemies or the other side, like it does make intuitive sense. If someone came to me and said, I got two software developers, you could work with one carefully, plans ahead of time, they know everything.

They work with you intimately for months to find every requirement, every need you have and they come up with contingencies and solutions and a complex architecture. The other guy, he's going to just try stuff. The one thing he guarantees is it's going to fail in the beginning and he's going to adapt over time.

Kent Beck: 00:43:55

No, every day he or she is going to give you a demo. And based on what you say in Response to that demo Tomorrow could be a completely new day.

Adam Davidson: 00:44:05

I'm on Team Kent Beck, but I can understand the other side. It's not hard to understand why someone would.

Kent Beck: 00:44:13

Sure. You optimize the warehouse by 4% and you get 4% better. Whatever, whatever, you know, cash. Yeah.

Adam Davidson: 00:44:23

Right.

Kent Beck: 00:44:23

You, you, you invest in another 20 salespeople and you get 20 sales people's worth of sales out of it.

Adam Davidson: 00:44:31

Right? Yeah.

Kent Beck: 00:44:32

Then the software developer says, I'm going to give you a demo every day and I'll respond to what you say. And you're like, yeah, but what am I going to, you know, over the next six months, I'm going to spend $10 million.

What am I going to get for my $10 million? And I said, every day I'm going to give you a demo.

We can't, we can't know if I told you now, if I promised you, here's exactly what if I spent three months promising you exactly what you're going to get. And the first thing you said when you saw it is, no, this is all wrong. I would have wasted half of your money. I don't want to do that.

So the, the more discovery there is, the more value there is in embracing change. I had my flavor of this, which was, and started out in an engineering world with test driven development.

So, you know, the software works with refactoring so that you can continue to make changes with continuous integration. So even if you have teams of people, they put the software together many times a day.

This is in an era when you might put the software together from a bunch of people's efforts. You might do that every few months. And it was a giant hairdo, as you can imagine.

Instead, we're gonna, we're gonna put it together 10, 20 times a day. So I, that was my flavor called Extreme Programming, or XP for short. I needed a. It.

It's not a, it's not a great brand Extreme programming because people are, you know, yeah, bungee jumping, blah, blah, blah, whatever.

Adam Davidson: 00:46:13

Right? I want boring programming, I want rig.

Kent Beck: 00:46:15

Yeah.

Adam Davidson: 00:46:16

Rigorous programming or whatever it is.

Kent Beck: 00:46:18

Yeah, right. So I mean, we, we just call it xp. So that was my flavor. And other people had other flavors.

And then we got together because we were all being critiqued by folks who, from, from our perspective, were reactionaries. They wanted to go back to the. Let's assume nothing's going to change and I'll keep char you $10,000 per developer per year for my software. Right.

So we got together and said we're going to have to like, what, what is it? What's. What are the basics that we can all agree on? And that was. There was a series of meetings and that resulted in the Agile Manifesto.

Adam Davidson: 00:46:58

There were literally, I mean, it's like the Council of Nicaea or something like, it was literally people getting together and saying, I think we should test first. And other people. You shouldn't test first. You should.

Kent Beck: 00:47:09

That's not essential. The essential is blah, blah, and it's a bunch of big egos and I certainly own one of those.

Adam Davidson: 00:47:15

So we don't have to spend a lot of time on this. But when I think of Agile, I think of sprints or. I mean there's these terms epochs. And can you just.

For people who don't know, just a quick tour of what Agile means.

Kent Beck: 00:47:29

It's a form of relationship between the people who need the software and the people who can build the software based on incrementally over time, developing trust by producing concrete stuff that helps a little bit at first and listening to the feedback from the actual usage of that stuff. That's Agile.

Adam Davidson: 00:47:53

Wow. See, my mind goes to all these rules because when I've had Agile, there was an Agile process that.

Kent Beck: 00:48:01

Is this a swearing?

Adam Davidson: 00:48:03

You're allowed.

Kent Beck: 00:48:05

Fuck the rules. Yeah,.

Adam Davidson: 00:48:08

Right.

Kent Beck: 00:48:10

If that helps the relationship. Let's say I'm writing your flashcard software and you're using it on some cycle, whatever that cycle is. Maybe it's every day.

With larger teams it might be as long as a week. A week is forever in my world.

There's a lot of people who think, well, we can't go faster than any more often than two weeks and my head will explode or whatever. I just think that's a symptom of poor execution.

But let's say once a week we get together on Monday and we say, what's the most important thing for us to work on this week?

Oh, well, if we add up 26 of those weeks and we have a half year's worth of development, can we make some predictions about what we'll accomplish in a half a year? Sure, we can make some, but we shouldn't spend much time on them because they're bound to change.

If that's the assumption that they're bound to change, then let's just get together on Monday and we'll say, what's the most important thing to work on? And we'll get to work on it. And then on Friday afternoon we'll have a beer and we'll go, how'd that go? Oh, this was slower. Than expected.

This was faster. This thing came up and we adapted to that. So we didn't do this other thing that we thought we were. Okay, fine.

And then everybody has a good weekend and they're rested and eager on Monday when they come back in. That's, to me, that's the essence of it.

Adam Davidson: 00:49:41

How does, like, a client, like, let's say, I don't know, I'm just trying to think of some big enterprise software thing. Like, let's say I'm a. I don't know, I'm a bank and I want a new way to maintain bond trades. I'm just making something up.

But I have some very specific thing that there's no existing software to do. And we have some particular approach to trading that no software can accommodate. So I have some very real, like, business cases.

Maybe I'm willing to spend $10 million, but I really need it. Need something like what you can't literally say to them. I don't know. We'll see. Let's meet on Monday. Like, what is that con.

Kent Beck: 00:50:20

Why, why can't you. No, let's. Let's do the first week, and if you don't like it, don't pay for it.

Adam Davidson: 00:50:27

Is that really. How.

Kent Beck: 00:50:29

To me, that's the ultimate. Every Monday, the bank brings in a bag with $100,000. It's got to be expensive because if this works, it's going to be awesome, right?

Let's stay focused on if this works, just how good this is going to be compared to the people who bring in two senior architects and 100 junior programmers who don't know Dilly and. And build the specification for six months.

No, we're going to give you some software at the end of the first week because on Friday we want to demo something to you because on Monday we want another bag with $100,000 it. And then one Monday, you come in and there's no $100,000. And you say, thanks for all the fish, and away you go.

Adam Davidson: 00:51:18

Right.

I used to do this consulting work where I would charge a lot of money to help big executives kind of figure out how to communicate their company's story. And they would always ask, how long does it take? And I'd be like, My answer was always, how long does it take to fall in love? Like, it's.

I don't know. Like, I. And at this moment, I know you the least. And so I sometimes can. I mean, I can literally, sometimes figure it out in 25 minutes.

It's the easiest thing in the world. And Sometimes there's a deep contradiction internally in your company.

That means that the reason you don't have a clear story is because internally, the, you know, the CFO and the CEO don't agree on the strategy. And so they're telling. They're papering over differences or whatever it might be, but they don't like it.

They want to hear, like, three weeks and you'll get this. And I'm sure that when the market demands that, it gets people off for that.

Kent Beck: 00:52:18

And that creates wildly misaligned incentives.

Adam Davidson: 00:52:22

Yes. And I guess I have to admit, I have at times been like, all right, enough. I'm just going to.

Fundamentally, what I promised is words on a document so that you'll pay me. And so I'm going to give you words on a document so you'll pay me. And they're not good words and they're not going to solve anything.

And you're never going to look at this again. But I got to get this contract over with, and those are bummers. I never feel good about that.

But the alternative of saying at the beginning, when I know the least, and it's the same with software. Right on day one, you know the least that you'll ever know about this challenge.

Kent Beck: 00:52:55

Exactly. That observation, if you take that observation seriously, it completely restructures the sequence in which you do your work.

It doesn't change the work. By the time we're done, you still have flashcards and sound and video and whatever, spaced repetition and all that good stuff.

But it changes the order in which you do the things that get you there to maximize learning and adaptation instead of to minimize learning and adaptation?

Adam Davidson: 00:53:31

Right. So. But will you have in the beginning, like, a conversation with, say, our banker that says, like, yeah, all right, these things. I can really.

I'm pretty sure we could do that. That seems easy to me. I don't really know enough yet about these areas, but they don't seem impossible. This. I'm pretty. I have no idea right now, but.

But I bet in three weeks you're going to want something different because you're going to see. Is that the kind of conversation you have?

Kent Beck: 00:53:57

Sure, you can, you can have that. You can have that conversation. And especially about outcomes.

Now, in bond trading, it turns out to be easy because it's about how much money did you make right at.

Adam Davidson: 00:54:09

The end of the day? Yeah.

Kent Beck: 00:54:10

And you can. But you. You'd also like to have a sense of why aren't you making that if that money already, if you've identified there are some Leaks in your game.

In poker, we would say there's leaks in your game. Well, yeah, you'd like to know what the leaks are. And then. Okay, so this is probably worth addressing.

Adam Davidson: 00:54:34

All right, let's now get into our members because what, what I would like to see is more of our members doing two things. Messing around on their own with code and actually being developers, like my Tibetan flashcard.

That might mean solving a problem just for you, but then also I buy this idea that software development can now become just an ongoing part. It doesn't have to be this huge barrier expensive.

Like now we're doing a software project and you have to go to another part of the building and have meetings. And it can just be an ongoing thing. You could, could have some software that changes every week as your needs change.

You could have software that you create for three days just to solve a problem and then it goes away. You could have a vague idea that you try out and it doesn't quite work. I mean, you can do all of that maybe with a developer.

And it feels like this is kind of the apotheosis of Kent Beck's life. I remember, was it two years ago.

I remember seeing a tweet by you that said, as I remember with you, there was like a period where AI was a thing and you were like kind of at arm's length.

And then you went, you jumped in and I remember you saying a tweet that said, I now realize that 90% of what I do no longer has any value but the 10%. Something like this, I'm not quoting it exactly, but the 10% that remains is more than 10 times as valuable as it ever was.

Does that ring a bell or do you not.

Kent Beck: 00:56:05

Yeah, yeah, that was, yeah, that was my most popular tweet ever. And it's. 90% Of my skills are worth $0.

I might still enjoy doing them and I might choose to do them for the, the internal satisfaction, but nobody's going to pay me for 90% of the things that I'm good at, but that the other 10% are worth a thousand times what they were before. So, yeah, now there's a little hyperbole, but it's absolutely true. And it's that that has borne out.

Being good at software development requires a bunch of skills. Some of them are quite high level.

Okay, how do I maintain a vision of where this whole project is going in spite of details and crashes and changes and hirings and firings and whatever? So maintaining that vision is a critical skill setting.

Milestones, Breaking that vision down into, okay, the next thing to accomplish is this and the next thing to accomplish is that, but you know, and then some other stuff out in the future. That's a really important skill.

But the way you would, you would exercise that pre GENIE is you'd make one of those big strategic decisions about what the next milestone is and then months would pass and then you'd make another decision. Big strategic decision.

And part of the difference is those strategic decisions come once a day now because you accomplish some milestone and then what do you do next? Well, you have to maintain the vision. Like, are we still trying to accomplish the same kind of thing we were trying to accomplish before?

Have we discovered a new goal that's, that's even more valuable than what we expected? You're going to exercise those high level skills 10 times, 100 times as often as you used to. So if you have those skills, it's really valuable now.

There's other things I'm good at, like where do the spaces and tabs go so that somebody reading this code later can really understand the essence of the complexity with no extra barriers. It's a skill. I love getting into code at that level and tweaking and tweaking.

It's kind of like wordsmithing in writing where you find exactly the right words or the exactly the right phrase and it feels really good. But in programming that's not nearly as leveraged as it used to be because it's a GENIE that's likely to be reading this code next.

Adam Davidson: 00:58:52

I just ask if I need to know, explain what this code is. I just ask the GENIE and it tells me here's what that code does and if there's a code block, I just dump it in and say, what does this do? Yeah.

So the whole reason I called you for this conversation was what is what endures? And pretty much everything you've talked about indoors in my mind, because you haven't.

The thing that I picture is like software and my regular life are just. There's not a big barrier between them. You know, just like we're all kind of fumbling through life, making it up as we go along.

Some of us admit it more readily than others, but. And you're just saying software is like that.

It's not a secret place where, because I think a lot of people, including myself, have looked at developers as they're magicians with special skills and they know secrets. And I just have to ask, you know, oh, they'll do it or they'll tell me whether or not it can be done. I just want to get at this idea.

It seems like it is the culmination of your work.

The way this ability to just program in English and in English language, program as you think and as you solve problems and then putting some structure around how you go from, huh, I'd kind of like to do something in a better way to an actual tool that I can use.

Kent Beck: 01:00:12

So I don't think you, I don't think the essence of it is programming in English. I think the essence of it is programming in cycles.

Adam Davidson: 01:00:20

So explain that a bit.

Kent Beck: 01:00:21

So, so yes, you use a prompt to tell the GENIE what change to make next. That part's true. But you know, let's take your flashcard software. You came to me, you said, I need this flashcard software.

I say, okay, it'll be $50,000 for this list of requirements. And then you get the software and I get the 50,000 and then we're done and it's one shot and we're finished.

The essence of what we're talking about is we don't do that. You, you type a prompt.

The fact that it's a prompt and it's not a hundred dollar bill is, is not so relevant as the fact that you're spending your money $100 at a time instead of spending $50,000 once and getting something which inevitably is not what you actually wanted. Instead, you're gonna, you're gonna do a little bit of development. Chug, chug, chug. No, that's not it. Little like this. Chug, chug, chug.

Oh, yeah, that looks good. Now, can you add one of these? Chug, chug, chug. The, the. It's the, it's that iteration, that assumption that you're going to be driving.

You know, when you drive, you don't point the car exactly at Wichita, Kansas and then go to sleep.

No, you're, you're, you're paying attention to the road and the road conditions and the other cars and where you're trying to get to that that's really important.

And I would say for your, for your listeners from my seat, usually my seats in the engineering, in that weird room with the weird people, the maintaining that vision of word. Hey, hey, folks, we're trying to get to Wichita, Kansas.

In spite of all the crazy that happens around you, that's the one skill that's really hard to generate in that room that is just heaven when an executive supplies that.

Adam Davidson: 01:02:33

I see, right.

Because you can get completely caught up with like your, I don't know, you're in Tulsa, Oklahoma and you're like lost in traffic and then you decide to engineer a new fix for your engine and you're, you know, getting in a conversation with a bartender and like, you're just like, law. And then you need someone sitting next to you like, dude, no, we're going to Wichita. This is.

So if, if we're thinking in cycles, the cycles are now either they're very much shorter or you can just get a lot more done in the time.

Kent Beck: 01:03:04

They're shorter, they're cheaper, there's less at stake in any given cycle. So if one doesn't go, well, we just chuck it and go, yeah, yeah, no, no, no, nah, knock it off. Go back to the world as it was 45 minutes ago.

Who cares? And that same cycle might have taken a week or a month pre Genie. So there's a lot more at stake if you screw up.

So you try and make things perfect, which increases the chances that you're gonna have to throw away everything that you do.

Adam Davidson: 01:03:38

So if I were hiring you now and I want my flashcard or whatever it is. So first off, before AI, I think I never thought of hiring a developer.

I've hired developers now because I'm doing enough development on my own that I know what I want and I know sometimes I know what I can't accomplish, but other times I know, well, maybe I could, but they'd do it faster. I actually hired a really great developer who's just my mentor. She just meets with me once or twice a week.

I kind of talk her through what I'm doing and I had a call with her earlier today.

I'm doing a much more ambitious project where I'm basically trying to embed all my knowledge about storytelling into a multi agent app so that business people could like dump in their website or whatever.

And it can, I want to see how close I can get to, you know, what if they hired me and it's way more ambitious with a complex front end and back end and all these API calls and it's kind of Frankenstein's monster. And she walked me through an easier way to do it. And then I was like, let's just throw it out and start over. And it was three days of work that.

Am I throwing it away? I don't feel that way. I learned a ton. If it was three months of work, you know, that would feel a lot different. Or if like. Yeah.

And that to me is, is so thrilling, like both, that I could just gin something up. And so our first meeting I'm at least coming with, like, a sense. Like, I find when I write my own.

And saying I'm writing my own code is, like, embarrassing because I don't know what I'm doing. But when I create a tool,.

Kent Beck: 01:05:17

Who owns it more than you do, though?

Adam Davidson: 01:05:19

Yeah. All right, so I do like to end on some kind of takeaway. Useful. So. All right, here's what I got from what you've said.

Kent Beck: 01:05:27

Oh, now we're going to try and be useful.

Adam Davidson: 01:05:29

Yeah, to me.

Kent Beck: 01:05:32

All right. I can shift gears, Adam. No problem. Problem. Okay.

Adam Davidson: 01:05:37

I will say the number one thing is I want to come up with something to work on with you. You just. It just seems like that would be so fun. So, yeah, if we could brainstorm some. Something to mess around with together.

I mean, maybe we could for the members, just have that. Do. Do a thing. You know, let's. Let's. Yeah, let's talk about that. Here's what I got, though.

The biggest thing I'm taking away from is to actually embrace my amateur status. You know, there's this. You know, it's like that zen idea that beginner mind has many possibilities, expert mind only has one. Like.

Like the things that I feel insecure about, like, oh, I hadn't thought through that part. I hadn't thought through that. Oh, you know, like, as I'm coding, as it gets more complex, I get kind of embarrassed.

Like, oh, I guess I don't know what I'm doing. I didn't think about that. But you're actually making me.

It's not that there aren't things to think about, and I probably do make just dumbass rookie mistakes, but to actually embrace that, to think of this not as the software is the finished package. That is the platonic ideal. And I either get it or I don't. And if I don't, that's a failure.

But rather, it's just a serious, you know, just like life, it's a series of steps in what we think is the right direction.

Learning from that, taking a step left, right, back, forward, whatever, based on that information that I don't know, that just feels very exciting to me, very inspiring.

Kent Beck: 01:07:05

The thing that I loved about it. So I have not been on the forefront of augmented development. Like, three years ago, I was reluctant to dive in.

And the magic moment for me is when I realized, okay, here's the thing that happens when you're a junior developer. You don't know what would be cool to make, build.

And as you become a senior developer, you realize, oh, If I had a program that did this, then this other problem would be easy. And if I had a program like this, and. And then comes the.

The tragedy of experience where you realize, yes, those things would be cool, but they're just way more work than they're worth, all of those things.

And so you become cynical and embittered and you realize, oh, there's all this software that would really make my life better, and I can't afford to build any of it. And that's a principal engineer, is that point at which you realize this. I can work on one thing and maybe one thing on the side, but that's it.

And those are going to be big projects. And I'm going to have to abandon all these other dreams that I have.

And the moment that's just magic for me, and it sounds like you've come to a similar experience, is when that universe of what I could do next suddenly expands. You think, well, I could, you know, I want to see the tides and the moonrise and the moon phase, you know, on a. On a wall display.

Oh, yeah, I could do that. Right? That's one of the bajillion things that I could do.

And so that expansion of the possibilities, not just for professional programmers, but also for. People just have problems they want to solve or they want to learn Tibetan faster and. Oh, oh, well, yeah. Oh, too bad. No, no, no.

You actually could exercise this muscle that you've just discovered and make learning Tibetan go more smoothly for you. And whether anybody finds value in it or not, completely irrelevant.

Now, every once in a while, one of those is going to be a jackpot, and other people will find tremendous value in it. But everybody's universe of possibilities has just expanded. And the realization of that moment is really a special moment.

Moment in the development of technology.

Adam Davidson: 01:09:46

It is, yeah. I'm just finding it a giddy time in my life. It's. It's. I say this too often, and I think it.

It's got to be boring to some, but, you know, I was in radio for 20 something years and then went into podcasting. And it's a similar thing where there's only a couple hours a day or four hours a day of original radio and public radio.

And each of those shows had, you know, tens of millions of dollars behind them and 12 approvals for every story that got on the air. And then in my late 30s, I suddenly found I can just do whatever I want. And if every now and then something's gonna hit and it's thrilling.

Oh, yeah, yeah, I Just. I joke about mammalian reproduction versus insect reproduction, where mammalian you want to like lovingly.

You get one or two shots a lifetime, and you want to really make sure they survive. And insect reproduction just will produce hundreds of thousands. Some of them will work, some of them won't.

Kent Beck: 01:10:51

Anyway, well, approximately one or two will survive.

Adam Davidson: 01:10:58

I love talking to you. I want to talk more and I want to find a way to. To build something with you because I think.

Kent Beck: 01:11:05

Let's do some kind of a live development session and see what comes out of it.

Adam Davidson: 01:11:11

Yeah, let's do that. I will. I actually have your number. I'll text you and we'll find a time. Can people get in touch with you if members want to?

Kent Beck: 01:11:18

Yes, absolutely. Sure. The best way is to get in touch with me on LinkedIn. Honestly.

Adam Davidson: 01:11:26

And most members are friends with me. I'm friends with you. They can find you easily. All right.

Kent Beck: 01:11:32

Yeah.

Adam Davidson: 01:11:32

Kent, such a joy. Thank you so much both for this conversation.

Kent Beck: 01:11:36

My pleasure.

Adam Davidson: 01:11:36

All you've done.

Kent Beck: 01:11:37

All righty.

Adam Davidson: 01:11:38

Bye.

Kent Beck: 01:11:38

Bye.

Adam Davidson: 01:11:39

All right. I hope you enjoyed that conversation with Kent Beck. The takeaway I keep coming back to is his reframe of what it means to be a beginner.

Right now, that beginner's mind, the thing a lot of us feel a little embarrassed about, turns out to be an asset. Jump into the discord and let us know what you're building or what you'd love to hear more of on this podcast.

As always, I'm Adam Davidson, and this is the Feed Forward podcast.