Kent Beck: The human part is the hardest part in software engineering. This is the biggest cosmic practical joke ever. We were promised, "Here's this computer and if you completely understand this computer, you'll be fine. That's all you need to do."

Host: When did TDD come along?

Kent Beck: I was just kind of farting around and I would write the test before I wrote the code. And I can remember laughing out loud cuz it was such a stupid idea. Why would you write a test that you know is going to fail? TDD is a good example where it almost went out of style completely. The big part of it is I work on something for a while and then I switch to something else. I moved on to the next thing. TDD is out there [music] 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. Extreme programming was born. I didn't want Grady Booch to ever say that he was doing this thing. So I had to pick a moniker that was unattractive enough that somebody would try and steal it. A little bit of thumb the nose at the establishment. Extreme sports were there. I like the analogy with extreme sports.

Host: 17 people rolled, but you're the first one listed. The Agile Manifesto.

Kent Beck: Things weren't going very well because there's all these people and, "I want my stuff in." "No, I want my stuff in, and that contradicts your stuff." And we took a break. We walked out and [music] Martin and Jim Highsmith stayed behind. When we came in from the break, there was the basics of [music] the manifesto.

Host: For a couple of years, we've had AI alums. So, one of the things is that the pace of development is definitely accelerated. One thing I wonder... Kent 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 Kent grew up with computers in the 70s and how he fell in love with Smalltalk. The origin stories behind TDD, Extreme Programming, and the Agile Manifesto, and why "Agile" the word was a mistake. Lesser known stories like how he got fired from Apple, Kent'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-plus years, and many more. If you'd like to understand how true legends were shaped by the industry and shaped 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 is 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 agent code today. This episode is brought to you by Turbopuffer. A fun fact about Turbopuffer is how they became the search engine for AI agents. It seems like every week they add a new use case from one of the leading AI companies. RAM, Lorra, Harvey, Granola, they're all on Turbopuffer. Or as the team likes to say it, they're all puffing. 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 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. Turbopuffer 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 turbopuffer.com/pragmatic.

Host: And it's so good to have you in person on the podcast. Guy, it's great to talk to you again. Yeah, I wanted 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.

Kent Beck: Yeah. 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're 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.

Host: Interesting because one thing that is so obvious with LLMs is they just code really quickly, right? Like, 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 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." 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?"

Host: As we're talking about software engineering, you 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, like 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... 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... empathy is 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.

Host: So I'd like to go back to right there, to the very beginning. Cuz so many people know you from your books, from a lot of the techniques that you've co-created or 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...

Speaker B: Valley. This is before the invention of Silicon.

Speaker A: Oh, this was before.

Speaker B: Yes. Before there was this is when there were still uh 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.

Speaker A: Probably weighed

Speaker B: 65 or 70 lb. Yeah. Yeah. It was

Speaker A: 65 lbs.

Speaker B: And it had uh it had Nixie tubes. Nixie tube is this is before seven segment LEDs cuz LEDs hadn't been invented. uh you'd have a uh an incandescent light bulb with 10 filaments in the shape of the numbers. And my first program was uh 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 uh wrote a program that would count up and down cuz I loved watching this go back and forth and back and forth and back for hours. I could just was

Speaker A: mesmerizing. Oh,

Speaker B: 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 uh 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 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 the 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 and this was very early '7s right Microsoft 72 maybe so Microsoft wasn't even founded founded in 75

Speaker A: what was it like in terms of how common or uncommon were these machines means how much or little did you even think that they would go anywhere or was it just just a a fun thing that has just been invented?

Speaker B: Probably the first wave of miniaturaturization was the programmable calculator.

Speaker A: Mhm.

Speaker B: So the one that your dad brought home.

Speaker A: So no, the like handheld calculators. Okay. So, so, so the 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.

Speaker B: It'll probably $2,000 location.

Speaker A: Yeah. So you 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+ and that would pop stuff off the stack. And then the HP45 came along and it would 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 808 and the 6800 and my dad and I soldered together our first 600 6800based machine. Then we were programming in assembly language. Then out came basic then

Speaker B: this was mid70s.

Speaker A: 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. 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. And then when it came to college, you you chose University of Oregon, right?

Speaker B: Well, University of Oregon kind of chose me because no none of the other places I applied accepted me.

Speaker A: No way.

Speaker B: Yep. And what did you study there? How how did your college years go?

Speaker A: Well, the first year was computer science. And

Speaker B: so they already had a computer science. Yes. Yes. We had invented computer science by then. The first year was CS. and and I enjoyed it, but I 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 some flyers for uh 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. So, [laughter]

Speaker A: wow.

Speaker B: So, I'd been playing I started playing guitar when I was eight, kind of the end of the folk boom. Mrs. Card at a summer school class and uh uh there was a guitar laying around at our house. And so I I went and 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 and everybody else was kind of where they were before, but I would have mastered some picking pattern, 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 and 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 of 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 uh in another year and and uh finished that. And so and as I say, I just ended on the wrong year. Yeah. Because I I I checked I think it was eight years in total. uh that you spent at Oregon at University of Oregon.

Speaker A: 5 years full-time and then I had a hard time finishing my master's thesis.

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

Speaker A: It was a novel query language. Not surprisingly, I did not get along with the authority figures, which is a 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 gonna 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, but you completed it.

Speaker B: I did complete it. It is important to complete things that in 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 uh as the Reverend Jesse Jackson said uh I'm a tree shaker not a jelly maker and that's definitely me. Yes it's true true for your work as well also for software. Well, I keep I keep switching topics. That's uh that's something that'll probably come up as we go through the various things that I've worked on.

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

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

Speaker A: Tektronics was an interesting one because this is where you met Ward Kunigum, right?

Speaker B: Yeah. So, uh, Tektronics had invested early in this crazy object-oriented programming language

Speaker A: ...called Small Talk and was trying to make a commercial go of it. And I got there and the 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. So I dove right into that.

Speaker B: 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?

Speaker A: There's a beautiful paper called the design principles behind small talk by Dan Engles 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 small talk language, and another was a language of interaction, overlapping windows, mice as pointing devices, panes, scroll bars, those were all things that uh were pioneered out of the user interface. Those things are kind of ordinary today. But Small Talk, 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, um, maybe, uh, 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 in within reach for anybody.

But what what I found beautiful was that the language pushed its own mechanisms to the absolute limit. So everything is an object in small talk 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 another object as a parameter. If that other object happens to be another integer, then you add them together.

Speaker A: This leads to interesting things like there are no control structures defined. So no if then 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. Just returns null. Everything is built out of the same kind of substrate.

There there's very few special cases in small talk which means that sometimes you have to get clever to understand things like h how does how do how do conditionals work but also when the time comes for you to build abstractions you you don't have a bunch of special cases getting in your way. 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 coughlin or swift or any of them they they have things like control structures and reserved words why would you reserve words how rude the programming language should give me as much vocabulary as possible

Speaker B: but I do notice that with small talk 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.

Speaker A: 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 cobalt forransc alascal for a long time and we were used to 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 in fact,

Speaker B: >> really.

Speaker A: >> 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.

Speaker B: >> I've heard this recently. [laughter]

Speaker A: >> Exactly. But seriously, like this was what they were saying where 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.

Speaker B: >> Yeah.

Speaker A: And and to a degree it was true. We would people would come in. So built a workstation, there weren't workstations. Tecttronics built a workstation and started to sell it with Small Talk 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 solve the 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 a significant step forward as opposed to I'm going to write a thousandpage requirements document and then wait 8 years and not get what I want which was the alternative that we were offering at the at the time.

Speaker B: 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 lots of corner cases that aren't covered. It's impossible to to modify and evolve. Yeah. But so far this story with small talk and Tektronics selling machines that come with small talk make everyone more productive. Clearly it pays for itself. That sounds great. But then what happened?

Speaker A: There were alternatives that were easier to understand. So for example, small talk syntax is uh 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 small talk. 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 small talk.

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 a 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.

Speaker B: Now while at Tektronics you work with War Kunagum who would later become the developer of the first ever wiki. Uh he had a huge influence or he helped create design patterns. He also helped with extreme programming. Can you tell me about what it was like working with him and and how you and him started to get into design patterns which back then didn't exist right this was something you you would invent later

Speaker A: we needed to give training classes on small talk 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 small talk 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.

Speaker B: And I guess for for those who don't know prologue is this declarative language is a very different way of thinking. No no no

Speaker A: variables is I I think

Speaker B: no no it's got variables. No variables is FP box. Oh, this FP sorry, but it does have some some funky stuff. I I I used it a long time ago.

Speaker A: It's fun.

Speaker B: 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 small talk 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 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 well, I wonder if we can make Small Talk do this because the universe of of what it meant for a computer to support programming was just exploding. We had the this high resolution screen which nobody had ever had before. we had this dynamic language uh 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.

Speaker B: So uh 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 uh picking powerful top level goals and then making something that does that. But I was this 24 year old punk with attitude and he he didn't let me touch the keyboard for a while. I could watch him and then eventually I was like h 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 at 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 why is this called this and not that pull out a thesaurus and look it up and find just the right word for things and then 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 something like this. Oh, I get it. I get it. And then he'd take the keyboard back.

Speaker B: 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.

Speaker B: 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 6 or 12 months of really working together intensely. Even if one of those weeks failed, you know, we'd we'd have our coffee Monday, Tuesday, Wednesday. ah, 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.

Speaker B: So, we developed a wide range we of programming tools and applications, some foundational stuff. So, we had a uh graphics editor called Hot Draw because we 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.

Speaker A: Yeah. I I have a photo of of early draw.

Speaker A: Yes, absolutely. And 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 not the exact ideas, but 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. Sounds like so you did this back in in ' 87 or something like that.

Speaker B: Correct. And because we had uh 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 was just this is so hot. We were just really excited about it.

Speaker A: Oh, that that's that's why that's why you called it hot draw. 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.

Speaker B: And with this, you subclass figure and now you have something that works in this 2 and 1 halfd 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 of 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.

Speaker B: And then you had it was a boxes and arrows uh 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 the words figure handle drawing uh 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 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 and figures and figures.

Speaker A: And do I understand that you actually had a physical thesaurus like a book?

Speaker B: Yeah. Yeah. An actual book with words in it.

Speaker A: You would actually as a programmer reach for this book with words and open up to find better words all the time.

Speaker A: Was this just you doing it or did programmers in general have like people that you knew that they also have the satarist?

Speaker B: We were on the far end of the obsessive scale for this. There were other people certainly who were fighting for the right words. But this just this just reminds me of how programming is 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 a thesaurus of 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 you know words your vocabulary was will start to grow there therefore making you a better programmer or someone who can write a lot more understandable or maintainable 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.

Speaker A: Yeah. And then later Ward went on and he got very much involved with design patterns. I can all now see with hot draw how you know the 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.

Speaker B: Yes, all of the pieces were working together for us. Um 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 uh 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 cuz 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 dinners are really important.

Speaker A: Oh, so this is in the domain of architecture like strictly physical buildings.

Speaker B: Yes.

Speaker A: Wow. So you got a lot of inspiration from this domain even though software is very much a virtual it's in our head right and or in the computer right.

Speaker B: So the patterns are the constraints. You can't just make any decision. You make particular decisions at 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 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's like, okay, a four-part motet, that's fine. and we don't need to have 60 different instruments doing 60 different things all at the same time just cuz 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'd 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 pains. 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 pains 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 a 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 small talk 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.

Speaker A: 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 and kind of flies off.

Speaker B: This is a seagull.

Speaker A: The seagull. The seagull. Because it should

Speaker B: You fly in, you make a bunch of noise, you crap all over everything, and then you fly out. Yeah.

Speaker A: Yeah. 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.

Speaker A: And then after Tektronics, you worked at Apple. I only realized this about you. What how did you get into Apple? This was in 1987. It's a very exciting time from my research. How did you get in there? What did you do there?

Speaker B: So, Small Talk was going up like a rocket at that time. Xerox had developed Small Talk. It handed it to four I think companies to see can you also implement it or is this something special. So HP, Apple, Tektronics and blanking on the fourth one. HP really didn't do anything with it but Apple and Tektronics ran with it. So Apple had its own implementation of Small Talk 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 knew about that project. It was getting too big for my britches at Tektronics. I learned a lot. You know, 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 Small Talk project, which ended up going nowhere cuz it really didn't make sense. Small Talk could work in quite a small memory footprint, but the only developer tools Apple really needed was a C compiler, Pascal compiler,

Speaker A: because that's what they built their software 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 the small talk wasn't going to do really do anything for anybody. Maybe school kids or something, but it wasn't driving Apple sales. People who bought Apple computers typically didn't want to do small talk. Right.

Speaker B: Correct.

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

Speaker B: no it was quite strong at that time it was growing fast um 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 as a big ticket item for

Speaker A: 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.

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

Speaker A: >> Correct.

Speaker B: >> And and their hardware.

Speaker A: >> 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 raised 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 K had moved to Apple and was working on a programming language for kids, another programming language for kids called Playground. Dan Dan Engles was there. So, a lot of the Xerox folks were were at Apple and I heard about Alen K's project and thought that was a dream of mine. Bite magazine had an article on small talk. 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 K's playground project. Now, I was horribly ineffective. Uh, ended up getting fired from that job.

Speaker B: >> No way.

Speaker A: >> Yeah. Oh, sure.

Speaker B: >> As as a programmer, you being inefficient. What happened?

Speaker A: >> 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, "Nah, 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, uh, uh, the it came to a head. I was the program chair for oops conference, which we probably should have mentioned earlier. Um there was this conference and it was the hottest conference and everybody who was ever anybody was there and it was growing fast and I was involved in it kind kind of stumbled into it but I was in ' 89 I was the program chair for oops right for oopsla and I spent a month just reading papers while uh 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 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 the playground project and 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.

Speaker B: And then I wanted to ask you about this 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?

Speaker A: You have this 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 going to be invoked when you send a message. And people were like, well, how do you even visualize, internalize? For me, I'm um I have kinesesthetic synesthesia. So, I can feel in my body if I'm looking at some code, I can feel in my body. It wants to go this way. It's

Speaker B: Yeah.

Speaker A: which is, you know, I've I don't know if I've met anybody else who describes their experience of programming in 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 these things 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 dah. So we would talk with our hands a lot. So he said, "Well, why don't we write these things down on cards, index cards?" So a 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 to you want the computation near to the data so that there's less coupling between them." which is a lesson that I I think uh kind of got lost in the noise. That's the fundamental design move in ob in designing object-oriented programs and I I think I stand behind that. So so have have the data be close to where it's used where the computation will happen

Speaker B: >> uh backwards

Speaker A: >> backwards

Speaker B: >> have have the computation move to where the data already lives

Speaker A: >> 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 just get the data and do whatever computation they need to.

Speaker B: >> If I'm going to operate on stuff that's on the inside of a rectangle like area.

Speaker A: >> Yeah. Do I have height time width scattered all over the universe or do I have an area inside the rectangle that does height and 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 I can represent the rang rectangle with two corners

Speaker B: >> or I can represent the rectangle as a top left a height and a width. Mhm.

Speaker A: >> 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.

Speaker B: >> Yes. And that means you can have looser coupling.

Speaker A: >> Correct. Understood. It's a good lesson.

Speaker B: >> Yeah. Yeah. Yeah.

Speaker A: >> And and even today cuz everything that we do is under the hood. Almost everything we do is object. A lot of it is object-oriented. And I don't think we think about these.

Speaker B: >> Yeah, I see a lot of criticism of programs written in object-oriented languages that aren't criticisms of object-oriented programming or design. So after Apple, you moved to a company called Maspar. 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.

Speaker A: While I was at Tektronics, uh, I got interested in testing. At that point, testing was a sociological divide. If you got A's and B's in computer science school, you got to program. And if you got C's, you had to be a tester. So, it really was like a status. I'm not going to test. I'm 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 uh status divide there was a tool divide. You had testing tools which would have their own kind of language and 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 Maspar that uh I

Speaker A: think is all ancient history. So we'd have to go you know dig through the archaeological 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 you a rollup of the results of it.

Speaker B: So this was pretty much a unit testing framework for small talk.

Speaker A: It was written in yeah the first version was written in small talk. So, Maspar was a Silicon Valley startup venturefunded intended to build an entire new architecture which was uh SIMDI single instruction multiple data. So, we would have a Taurus of process processing elements uh up to 16,000. So, you have 16,000 and they're connected in a toridal grid. So you could talk to the 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 um but for a tenth the cost and they needed a programming environment. So we built a programming environment in Small Talk that did some really cool stuff. You could you could single step a forran program and build a performance profile at the same time.

Speaker B: No way. So you built a runtime that allowed you to do in in small talk to interpret for example program programs and run them.

Speaker A: No the we had a 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 four trend programs running on 16,000 processors and great gobs of data.

Speaker B: That's awesome. Like when you're going from not just like you're going to lower level, you know, like building infrastructure that runs programs, but then I want to go back to to SUnit. So the concept of of SUnit, the the these concept you put together a test case. What was it? the test case,

Speaker A: test suite and test result.

Speaker B: This really became sticky because then there was JUnit which you later created with with Eric Gama and there's a whole suite uh nunit for uh I think that was fornet 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 sticky and why do you think it wasn't created beforehand?

Speaker A: 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 sometime and sometimes the programmers really did act that way. So I, 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 small talk. So, you know, and I was just used to how do I represent this as objects.

Speaker B: So, sounds like small talk as a language has been early to a lot of things. I sense a lot of innovation coming from small talk 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 if you or being forced to do so if if you wanted to do it.

Speaker A: Well there was an ethos that went along with small talk. 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 hop 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, uh, I'm I'm using a C compiler and I realize, oh, I wish C had this new feature. We're embarking on a multi-year project to go and like the huge barrier to entry to go to the next level. And in small talk by design, for example, you have 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 going to I see this format item here and I well what does that do? So that was very much part of the small talk 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. 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 t is kind of magic you know uh 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 something or other and it executes that one thing and then you Then assuming well then regardless you run the tear down 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 it's in the language but it's not really in the language at the same time.

Speaker B: 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. I want to jump to a few years later from to 1996 you started to work on a project at Chrysler and this is where you met Martin Fowler. What was this project?

Speaker A: I'd actually met Martin Fowler a little bit before that. So as early as the first oops 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 a 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 um for objects and how should it be different? That was the million-dollar question at the original 86 oops law. By the time 9495 rolled around, we were starting to get a clue what that would look like. There were I think uh the rational and unified process or the the things that would go into the rational unified process already existed by that time which was

Speaker B: Brady Buch was involved in that.

Speaker A: Brady BC Evar uh James Rumba Ivar Yakabson. So people were coming up with some kinds of answers. Ward had come up with his own uh answer called episodes written into 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 over again and the same is true turns out of of everybody. So you can find that episodes on uh 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 Masspar? 92. So I had been an

Speaker A: independent consultant for four years at that point. And there were a couple of workshops uh held in Snowbird. I don't know why we picked Snowbird, but somebody else did uh about this methodology question. Um, 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 uh analysis patterns uh at the time, which I knew about. So, I was excited to 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. Uh I had met Ron Jeff doing small talky stuff. I don't remember exactly how we met, but long story short, I came in as I know 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. Uh 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 small talk performance and they were using a database called gemstone which it was small talk objects small talk 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 I 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've been working very long hours. I said, "Send everybody away for 2 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 3-w weekek 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 3-we segment and another and another.

Speaker A: No, 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. And then so this is 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 as a concept of that it doesn't needs 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 and so all of these ideas just all came together.

Speaker B: >> Yeah. And then when did you give it a name?

Speaker A: It started going well. At first I was like I was excited. I was scared. I was excited. Then it started going really well.

Speaker B: >> So like the project started to go visibly well.

Speaker A: >> Yeah. Yeah. 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 C thesaurus trying to figure out what are the words

Speaker B: >> called us.

Speaker A: >> I thought we were really on to something that was going to be big. So I wanted to protect it. Apologies to Grady who's a good friend now. But um I didn't want Grady BCH 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 uh

Speaker B: >> you're you're now this punk again.

Speaker A: >> Yeah. Well, yeah. I still am, but [laughter] I'm just 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.

Speaker B: >> Yeah. And training and all that, right?

Speaker A: >> that seem impossible and are impossible if you haven't done all the prep. So it's accurate, it's edgy, it's the that word extreme and hence extreme programming was was born.

Speaker B: >> That's so that's the extreme part.

Speaker A: >> 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 extent at that time treated programming as this clerical task. We'll we'll we'll draw these diagrams and these diagrams and build this thing and the 14 ways to visualize this and then 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 uh 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 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 al alternate universe in which I sued them and failed and bankrupted myself and my children all starved to death. So,

Speaker B: >> Right. Right. Cuz this was right around the year late '9s and XP came out. Yes. Soon after, I think 2000 or 2001, something like that. When did XP extreme programming recall 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?

Speaker A: >> I remember the first talk about XP I gave I had some flyers to hand out. So I think it was at an oopsum on a panel or something like that. I I talked some about XP and afterwards people were give me a copy. No, no. Uh uh uh uh uh uh uh. 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 the upside, not the bomb, but the the upside of it was just starting to hit. They looked at other methodologies. It 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 going to work in a world that's changing as fast as the internet wave starting to crest, starting to come into, you know, the 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 going to 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.

Speaker B: >> Basically XP was giving you a way to move pretty fast and

Interviewer: nimble but also have a sense of stability not just going wild. 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, uh, test-driven development by example. And how did it relate to XP?

Kent: So TDD was an earlier test 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 a copy of it. Said, "Here's how you program." This was back in the days of taped 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, etc., etc.

Interviewer: Yeah. So it was always and then

Kent: 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 and then you really manual like actually

Interviewer: physically pulling a tape off and moving it over. Yeah.

Kent: And it 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 uh should I I should have a record in the output that like this.

Interviewer: So I see where we're going with this. You're you're defining the the output. You're before you start on the program.

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

Interviewer: Correct.

Kent: 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 sunit 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 on to something with with this this testing framework. And then I [clears throat] 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 SUnit. 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 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.

Kent: 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? You know, you push two things and you get them back in the right order. Okay. And this and uh dupe pop top is empty and finished. Where's the anxiety?

Interviewer: Oh, just gone. Oh, for the first time.

Kent: 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. Go going from this is a stupid idea. Let's let's try it. Absolutely. No, I made a 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 100 it'll fail. But that one time you won't have any competition cuz 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.

Interviewer: Well, 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. Uh it was it was a super popular book. I still remember I think I had a copy as well back in the the late uh two 2000s people were like doing you know group exercises developers were developing accordingly over time it it probably dropped I would say in the 2010s I saw fewer and few people doing it uh and it almost went out of style completely and now with uh with agents the idea is back because turns out it might take more time what not but agent agents can do that but it's a It's pretty useful for them to test themselves. 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?

Kent: I I think uh 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 Junit. 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 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 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. I 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, 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.

Interviewer: Test-driven 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 code today. Let me explain how it works. Antithesis 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, antithesis doesn't only find bugs, it gives you a perfect reproduction of every issue. I know this sounds close to science fiction, but it's actually hardcore engineering under the hood. Jane Street, Fly.io, and the CCD community ship agent written code with full confidence because they know it's been verified by antithesis. To see more case studies and details, head to antithesis.com/pragmatic. That's antithesis.com/pragmatic.

Interviewer: 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 works is all about. If you're building any SAS, especially an AI product, sooner rather than later, you'll need to get around building enterprise features. Things like O for apps and agents. Work handles it. SSO, skim, fine grade authorization built for how agents actually operate. The fastest growing AI companies entropic open AI cursor perplexity already trust work to solve these problems. Check out work.com.

Interviewer: And with this, let's get back to Kent and where the agile manifesto came from. I wanted to talk about the one thing that you're also very very

Speaker A: ... 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 in Snowbird? What was the industry like and and what made all of you come together?

Speaker B: 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 a process but that'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 I 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.

Speaker B: 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.

Speaker B: 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 Guten Berry, 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.

Speaker B: But we were meeting and talking about do 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,

Speaker A: strong opinions.

Speaker B: Me, not the smallest among them. So, uh, when we got back, Jim Highsmith and Alistair Cockburn, uh, convened another meeting at 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 um, 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 uh 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. And 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, we the the that format. We value these things, but we value these things more.

Speaker B: 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 alphabetical

Speaker A: al absolutely alphabetical.

Speaker B: So So when when people say, "Oh, you're a signator." as they know I'm the first signatory alphabetically.

Speaker A: And then what was the impact of the agile manifesto?

Speaker B: Oh, in instant instant people were so excited again were now the rumblings of the dotbomb.com. It it was still going up.

Speaker A: I I think so

Speaker B: it was towards the end

Speaker A: but definitely towards the end like but people were still looking for a like how do we do this? How do we do this stuff? How to build software quickly, cheap, reliably. Everyone's searching for the optional

Speaker B: with with optionality.

Speaker A: With optionality. Yeah.

Speaker B: 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 SUnit. I had SUnit. 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 SUnit. So we developed JUnit testing itself in itself on the flight from Vienna to Washington Dulles.

Speaker A: Wow.

Speaker B: And when we landed

Speaker A: on the plane, no internet. No internet.

Speaker B: Two and a half hours of battery. Like the clock is ticking.

Speaker A: Yeah. And no power adapter in the seat.

Speaker B: Oh, it was it was like a horsedriven computing. So we landed and and we gave Jayun to Fowler who was at at that oops and um the next day I hear you have a Java testing framework. Can I get a copy? So we made floppy discs, 3 and 12 in discets and and we were handing them out as fast as we could cuz there was so much demand for it. So that was the second time I've been through that kind of a demand product market fit column

Speaker A: Yeah. Yeah. Exactly. Product market fit. Um and then agile manifesto was the the next version of that where people were just really excited about it. beautiful piece of marketing to have the original signitories and then if you wanted to sign it,

Speaker B: you could sign it for for a while. I think they closed it after a while because it got too many people, right? But that meant that pe people felt invested. They were already bought in. They'd already attached their names to this thing.

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

Speaker B: So uh one piece of followup is that word agile part of the ar argument 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 I 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 going to say you're agile even if you're definitely not. So that was my objection back then and and that certainly played out. That word does not only doesn't mean anything anymore, it means something negative.

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

Speaker B: 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

Speaker A: ...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 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 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, "Nah, 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. Yeah, but everybody can't be the same programmer.

Speaker B: Yeah, 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 interchangeable >> technology. Yeah.

Speaker A: >> Well, it's 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's 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 that, 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.

Speaker B: Let's talk about what happened after 2001. So, uh there was a big do bus. Can you take us back to what it was like being in the middle? So you were in were you in Silicon Valley at that point?

Speaker A: >> 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 uh 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

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

Speaker A: >> It was horrible for me personally. The turning point was 9/11. I had 8 months booked solid work at very high rates, higher rates than I can charge now, even with inflation. And the day after 9/11, everyone canled. 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. It's overnight.

Speaker B: >> Overnight. Wow.

Speaker A: >> So, things had already been bad. There were there were big bankruptcies and the the pets.com and the whatever that that was already happening. And then 9/11 just shut down everything. That was a big shock for me and I ended up burning out um 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 had three really big part of market fits where people were after you.

Speaker B: >> Patterns even before that was also like that. >> But you were a star.

Speaker A: 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 knowing a message like that. Then I started getting messages, uh, 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 M and then I would feel really bad. And the way I think about it now is that 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 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 to do about me. But but that recalibration where I'm like, I'm trying to convince myself that I really am this awesome. No, I I get feedback that I'm not. That was a a a serious reset for me. So, I went through a bunch of mental health problems, couldn't work, c couldn't uh couldn't program at all. I had I started over with Sudoku and eventually I could do sudokus on easy and then eventually I could do them on medium and then I started on on uh uh crossword puzzles. Wow. 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 I nailed it and I went, "Oh, this is still fun. I can still do this." Uh but yeah, the kind of a lost decade from 2002, let's say, to to 2011 when I joined Facebook.

Speaker B: So it you really went from being on close to the peak of of of the industry or the professional, you know, like mountain if if if you will to just I guess just finding your way.

Speaker A: >> Yep.

Speaker B: Do you think something similar might have happened? Was it not for this sudden crash or being a this sudden or or was it just the intensity of of of everything just being pulled under out of under your feet? What do you think it was?

Speaker A: I think that people are coming to me with these expectations that I know I can't meet that it's going to blow up somehow eventually for sure. You can't just live the rest of your life like that. Then 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 going to 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 going to come. It said 35 or 40 or 45 and mine was at 42.

Speaker B: But then you in 2011, you got into Facebook. And I'm really intrigued by this story because at this time Facebook was uh 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 you've you've had all all these contributions TDDXP knowing how to build

Interviewer: 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 and income. Problem with book publishing doesn't make much money.

Interviewer: Yeah. Except in a rare cases for a guy.

Kent Beck: Well, in the rare cases in my case where Amazon self-publishing has been invented. And people buy your books in bulk. But outside of that, even for uh Yeah. It doesn't.

Interviewer: 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.

Kent Beck: I have to take [laughter] it here and then here on this podcast. 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. It's 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...

Interviewer: you wrote the book

Kent Beck: I wrote the book I invent you know blah blah blah and they clearly need it I could see because nobody's doing it very few unit tests at that time um which just shocked me how can this be so I said, "I put on the signup sheet TDD class for me from the Kent Beck." Just before my class was one on Argentinian tango and just after my class 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 signup. 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 gonna 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 quickly enough. Can I relearn software engineering fast enough not to get fired? And I ended up staying there for seven years.

Interviewer: And what did you learn? What made it work? Because 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 massive 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: Mostly.

Kent Beck: So, we had some very senior people with great leadership skills.

Interviewer: Aha.

Kent Beck: uh 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: You could check out there was a mono repoish thing.

Kent Beck: Yeah. And so you could just change anything and see the results 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 get another round of feedback. Then we had this phased roll out 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. Not...

Interviewer: like automatic roll back based on signals.

Kent Beck: Yeah. Not the whole [clears throat] 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,

Interviewer: Swiss cheese,

Kent Beck: it's the bad stuff sticks and the good stuff still goes through. Yeah.

Interviewer: So the Swiss cheese model even though there's holes everywhere as long as they don't line up for six layers of cheese then you're good and unit test would unit test been better maybe.

Kent Beck: 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 meaning an outage.

Interviewer: Yeah. Yeah.

Kent Beck: not a bad enough one to go through a incident review which is 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 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: What I know and what many people know is well Facebook for a long time did 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 roll out and the auto rollbacks which just does not exist in 99.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.

Kent Beck: Yes. And while I was there, so by the time I left 2017, Facebook was a very different place than when I joined. Over the first couple of years, Facebook became much more like

Guest: 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 of cops sev and it was the first time that people called 911 when Facebook went down.

Interviewer: >> Wow.

Guest: It was like oh crap we need to take this even more seriously than we've been taking it.

Interviewer: >> Okay.

Interviewer: >> Because we're social infrastructure and people just expect it to absolutely work. And what was it like inside Facebook? How the engineering culture uh how engineers work compared to the rest of the industry? because now you were now in in this bubble which worked very differently.

Guest: 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." And 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 I accidentally saved $5 million a year during my boot camp. No way. I was looking that 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 the whole that was photos and it was the biggest photos site in the world at that time. And I looked at it 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 d 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, "Oh, ops noticed that the demand on the photos machines suddenly dropped when we rolled your stuff out and they they can reccommission enough servers to save $5 million a year." And I was just farting around, you know? So there it was like the the gold rush and there's just gold nuggets sitting on the ground and you just pick them up. That 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 preIPO. The middle management, middle uh 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. they would give up. You know, you you talk to some team and they're like, "Well, we could really use you, but I think you really should go here cuz that's what's going to make my stock options go up the most."

Interviewer: >> Yeah.

Guest: >> 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 it was extremely novel. I collected a whole uh series of this. I found this manuscript the other day, how Facebook works. There were a bunch of policies that I had 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+. 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 a 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 set.

Interviewer: >> Yeah. But it feels like you were there during the golden years now. Now now it's morale is is terrible with all the engineers are being assigned without asking them to do data labeling. It's all turning into very different uh 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 coaching engineers there. What did you learn about folks who are already I guess pretty stand out if they got into Facebook. How in what ways could you help them or did you help them?

Guest: So about a year in I'd 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. uh I had six months to turn stuff around and in that uh 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 uh one of my friends at Facebook, a 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 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 3 weeks or four weeks or something. And two of the students worked out well and one of them got fired. But uh 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 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 them 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'd 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 was difficult or we'd all talk. I brought in a a storytelling consultant to to do an offsite. Uh, I hired uh Aaron Oorc uh was my administrator cuz this is 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 sameish. 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 which 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

Speaker A: individually. I would write classes that I would give and that 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 offsite with the top 1% of Facebook engineers. And out of the 100 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 always pleasant. It's not a pat you on the head and you're going to be fine. It's a don't like no, you're screwing this up. Go try this thing. Tell me how that works. Oh, 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 Darío 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. I'm having a blast. But this idea that we're code monkeys and jolt col in code out. Come on. To be honest, I do sense that Darío 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. No, he clearly wasn't one. This is fine. You can be it's 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. By the way, can we talk about now you 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 why why does this keep coming back?

Speaker B: Just we're kind of sometime. 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 geek, 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. It's why I play poker, by the way, so I get feedback when I have don't have good empathy. We often times are more direct than other people can easily handle.

Speaker A: Yeah. In the in the business setting.

Speaker B: 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 ass asking that question. And you I didn't realize it, but I was cuz 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 uh belligerence. 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.

Speaker A: Yeah, that's an invitation to have a conversation.

Speaker B: 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, go to 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, you know, the first Terminator movie where where he's got the little uh pull down menu of responses. Yeah, it feels like that often times. 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 the finance world, 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. Jumping to the present times where now for a couple of years we we've had AI LLMs but now we just call it AI or as you call the genie.

Speaker A: Yeah.

Speaker B: And

Speaker A: it grants wishes but it's not actually what you want

Speaker B: 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 are building software. What are you seeing so far? Talked a lot about how what software engineering really is. We talked about the understanding the communication the the learning as you are coding and it seems that that is definitely shrinking if not being taken away. That's a choice. But I'll let you finish your question.

Speaker A: Just look looking across the industry.

Speaker B: Yes.

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

Speaker B: Yeah. 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 SAS product. somebody vibecoded 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 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 blah blah blah blah blah blah. 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 uh 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 uh an another analogy, newspapers with classified

Speaker A: the the part the iceberg iceberg

Speaker B: you can see that you can vibe code the part of the iceberg that you can see.

Speaker A: So uh 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. And 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 and 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

Speaker A: 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 the the vibe coding replacers, we're going to see that kind of a naivity play out.

Speaker B: And what about for software engineers? Cuz 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 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 do

Speaker A: so the my inspirational motto is nobody knows so people come to me they say well how does TDD apply in 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 of product of software development. This exploration phase where you got to try a bunch of different things because 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 you 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 this is 3x,

Speaker B: right? Explore it.

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

Speaker A: Yeah. 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. So explore

Speaker A: explore is you 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 life span 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.

Speaker A: For 20 years, we've been up in that extract stand. 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. Now, 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 well, 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 who am I?

Speaker A: 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 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 to 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 it there. It 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.

Speaker A: I'll get these questions. Oh well I think we should blah blah blah blah blah instead of writing one test at a time maybe should 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?

Speaker B: 2001. Yeah.

Speaker A: 2001. The first oops LA 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."

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

Speaker A: This is home base for me. The writing of the playbook. I 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 a project called Arlo, which is a an object-oriented database. I have uh 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+ tree that's faster than Rust's B tree for some operations.

Kent: Wow. Yes. But also, I'm not a Rust expert. Like, what could a REST [Rust] expert do with these same tools? And 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 cuz like you, I have a newsletter. Unlike you, my newsletter is kind of small, but it's pretty big.

Host: I'm doing okay.

Kent: Now, how do I turn that into a sustainable business? Um, also I hired a business partner um 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 uh not being afraid to start over.

Host: And your whole career shows this from the very early days. TDD XV [XP] 3X, Tidy First, Genie.

Kent: 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 project I I'll take it I'll push it a certain amount and then the genie runs out of g 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+ tree looks like in Go. Here's an alternative to the B+ tree. This adaptive radics 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 minutia 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 it this is hog heaven. I've got 40 years worth of ideas. This would be cool. Uh it's too big. That suddenly are back in play. And I'm having so much fun making things that are real.

Host: I can see it. And you're sharing it as well, Kent. This was awesome. Especially doing it finally in person.

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

Host: This was a special episode for me. Recorded in Budapest, Hungary, right before Craft Conference 2026. It was a first getting to hear 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." Kent is [music] so good at summarizing very true things like this. When you struggle through understanding domain, represented in code, and write tests that prove that you got it right, you end up trusting your program. And when you do that work alongside other people, you build trust with these people, too. Kent'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 works, and the AI says, "It's all done." 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 Kent's tree shaker impulse is right back on his trying stupid things with AI. Finally, I appreciate how grounded [music] 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. [music] 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 notes below for how Kent and me both thought that McKenzie did not know what they're talking about when they want to measure software engineering productivity. Also check the show notes for related the pragmatic engineer deep dives on topics like tech, software craftsmanship, TDD and others. If you've enjoyed this podcast, please [music] do subscribe on your favorite podcast platform and on YouTube. A special thank you if you also leave a rating on the show. [music]